RE: Transferring File* to WebApps - redux

Eric,
Based upon your responses there are a couple of additional things we
need to check on, but I'll look deeper into the current specs for the
things that should already be supported.

The additional things are:

- how to safely grant access "outside the sandbox", which depends upon
ability to discover available file systems in persistent storage and
select arbitrary locations within them. We would prefer that this
functional capability is addressed within the File* APIs directly rather
than through an extension API in DAP, thus we may propose two additional
methods for the LocalFilesystem interface:
   getDefaultLocation: as from
http://bondi.omtp.org/1.1/apis/filesystem.html#getDefaultLocationN101E4 
   getRootLocations: as from
http://bondi.omtp.org/1.1/apis/filesystem.html#getRootLocationsN10253 
These methods can be covered under the general one-time prompt approach
or under the policy approach (once we have worked out how the File* APIs
are covered under that, e.g. by association of widget feature URIs).

- clarify the difference between "memory" and "persistent storage": "In
memory" usually means the content is in the working RAM of a device. The
File* specs talk about working with files "in memory" which I take to
mean that the file has been read from persistent storage into the
working memory of the browser (upon selection by the user), and is being
read or updated (with presumed writing back to persistent storage
later). The different may be subtle but is important. If what's meant
instead of a file copy "in memory" is that the webapp can *directly*
access/update a file in persistent storage, then I suggest the spec
terminology be updated to make that clear. 

Thanks, 
Bryan Sullivan | AT&T


-----Original Message-----
From: Eric Uhrhane [mailto:ericu@google.com] 
Sent: Wednesday, June 16, 2010 4:42 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: arun@mozilla.com; Robin Berjon; public-device-apis@w3.org; Ian
Fette; Web Applications Working Group WG
Subject: Re: Transferring File* to WebApps - redux

Sorry about the delay in response; I've been out of the office for the
past 10 days.  [Also, sorry Bryan--I forgot to reply-all.]

On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW)
<BS3131@att.com> wrote:
> I am not meaning to be unfair, perhaps the message is not coming
through
> clearly enough.
>
> There are specific technical requirements that we need these APIs to
> fulfill, that I indicated to Thomas in another email:
> 1) access filesystems on the host device

FileSystem/FileWriter/FileReader do this.

> 2) traverse directories

FileSystem does this.  Currently it's only specced to do so within a
per-origin sandbox, but the API could be used outside the sandbox if
another spec defined a mechanism to grant such access safely.

> 3) read files as they exist on the filesystem (not just a local
> representation in memory, as currently defined in the File API to my
> understanding), in bytes and lines

FileReader does this [not sure what you mean about a local
representation--if you can read an on-disk file, you're doing so via
memory].

> 4) write files (similar requirement to write directly to the
> filesystem), in bytes and lines, with overwrite and append options

FileSystem/FileWriter do this [details of appending still being hammered
out].

> 5) do the above programmatically in Javascript (not dependent just
upon
> user selection of an input element and interaction with a file
selector)

FileSystem does this.  And no, there's no need for the UA to prompt
the user on each access; permissions should be more on the order of
"can access temporary filesystem storage" and "can access persistent
filesystem storage", and need only be granted once.

> 6) provide security for this using the policy-framework approach as
> being defined for DAP APIs

This remains for DAP to work out.  It should be fairly straightforward
to add a policy-based mechanism to grant access to FileSystem APIs
[e.g. your example "documents" folder, via resolveLocalFilesystemURI,
mentioned elsewhere in this thread].

Thanks,

    Eric

Received on Friday, 18 June 2010 17:54:49 UTC