- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 16 Jun 2010 16:17:08 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Robin Berjon <robin@berjon.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Web Applications Working Group WG <public-webapps@w3.org>
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 <robin@berjon.com> 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/ >> >> >> >> >> >
Received on Wednesday, 16 June 2010 23:17:41 UTC