I am also happy with this suggested approach. - Maciej
On Jun 16, 2010, at 9:34 AM, Jonas Sicking wrote: > SOLD to the bearded french dude! > > Seriously though, this sounds great. > > / Jonas > > On Wednesday, June 16, 2010, Robin Berjon <[email protected]> wrote: >> Hi all, >> >> thanks a lot for this useful and frank conversation. Based on this input and >> stuff I've been ruminating over, I'd like to propose the following >> arrangement (in detail, so bear with me for stating some parts that may be >> obvious). >> >> • File/FileReader stays in WebApps. It defines all that you need to get data >> out of a File object and a way of getting hold of one of those through an >> HTML binding. >> >> • File Writer moves to WebApps. It defines all that you need to write data >> to a File (or Blob). It will also define a way to safely get that data >> saved, for instance through a download dialog. >> >> • File Directories and System moves to WebApps. It defines all that you need >> to frolic around a file system, exploring directories, creating and deleting >> entries, etc. It also defines access to a local sandboxed file system. One >> thing that it loses in the transfer is the DeviceFilesystem interface. >> >> • A new "Trusted File System Access" specification is produced in DAP that >> inherits the current DeviceFilesystem interface. >> >> A word on this new "Trusted" thingie. There are two goals that we have here: >> design wicked cool APIs that work in browsers, and design wicked cool APIs >> that can't work in browsers. The latter are expected to be used for >> installable apps (widgets, browser extensions, browser-powered apps, mobile >> apps) or other such situations in which a trust relationship — a situation >> that is becoming increasingly commonplace and where some interoperability is >> badly needed (at least on some basic things — e.g. we don't need each >> browser extension system to have its own separate file API — innovation can >> and should proceed apace on the more advanced stuff). >> >> Instead of trying to cram both aspects into the same specification, we use >> two, with a layered model that has the "Trusted" side add access paths. I >> know that some people have claimed that it would be impossible to produce >> web-safe APIs that could also be further opened up. I submit that the File >> family of APIs has shown them to be wrong: all that the trusted level >> requires is a single interface with all of two methods. >> >> This is a pattern that I can see being rather straightforward to apply to >> Capture (as a more formalised way of expressing previous "separation into >> levels" discussions), Contacts, Calendar... And if we do find a case in >> which it doesn't work, we'll cross that bridge then. >> >> WDYT? >> >> -- >> Robin Berjon - http://berjon.com/ >> >> >> >> >> >
