RE: Transferring File* to WebApps - Proposed path forward

Hi Robin,

It might be worth hanging on for Arun's response to my email this
morning before we get to a resolution on this.

Also on the proposed naming, the term 'Trusted' has a very specific
meaning and it could create ambiguities - i.e. we would not be defining
a "Trusted File System" Access. That is something completely different
(and I would love to see a Trusted Services API for access to Trusted
Execution Environments and Secure Storage by the way in the future) but
this is not it.

Cheers,


David.

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
Sent: 16 June 2010 11:57
To: public-device-apis@w3.org; Web Applications Working Group WG
Subject: Transferring File* to WebApps - Proposed path forward

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 11:23:41 UTC