W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: Transferring File* to WebApps - redux

From: Eric Uhrhane <ericu@google.com>
Date: Wed, 16 Jun 2010 16:41:33 -0700
Message-ID: <AANLkTin3rQpPOd1pw81ym2W7qaA4vAjqBsRTBkfqfCpy@mail.gmail.com>
To: "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>
Cc: arun@mozilla.com, Robin Berjon <robin@berjon.com>, public-device-apis@w3.org, Ian Fette <ifette@google.com>, Web Applications Working Group WG <public-webapps@w3.org>
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 Wednesday, 16 June 2010 23:42:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT