W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2010

Re: Transferring File* to WebApps - redux

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 15 Jun 2010 16:32:17 -0700
Message-ID: <4C180D81.5030002@mozilla.com>
To: "SULLIVAN, BRYAN L (ATTCINW)" <BS3131@att.com>
CC: Robin Berjon <robin@berjon.com>, public-device-apis@w3.org, Ian Fette <ifette@google.com>, Web Applications Working Group WG <public-webapps@w3.org>

On 6/15/10 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote:
> 5) do the above programmatically in Javascript (not dependent just upon
> user selection of an input element and interaction with a file selector)
> 6) provide security for this using the policy-framework approach as
> being defined for DAP APIs

I agree with you that those goals are incompatible with the File* APIs 
as they are currently evolving (although perhaps you can use these as 
the basis for interfaces and signatures, and swap out the invocation 
paradigm and the security paradigm separately within the W3C DAP WG).  
That being the case, let's agree to having separate DAP-oriented file 
APIs that address those particular use cases.  I think that we agree 
that the FileWriter and FileSystem APIs as currently written (and with 
the current editor, Eric Uhrane) can move to WebApps, where they can 
evolve along with the existing File API specification.

> Apart from the details of (1-4) above, which will help ensure are
> addressed in the current File* APIs (no matter where they are
> finished),I think it's (5-6) where the real differences are. If we need
> another API in DAP to address them, then AT&T will help ensure it gets
> done separately from the current File* APIs.

> The question of where you are represented and your ability to
> participate cuts both ways - the same is true for us. I think if the
> browser vendors want their products really to be seen as compatible with
> the Web application space (as compared to just dynamic Web pages), they
> will support the work in DAP as its there that non-obtrusive and
> inherently secure models for Web application access to device resources
> will be defined as APIs.

At present time, I think that the paragraph above accurately summarizes 
a technical rift between certain members of both working groups (DAP and 
WebApps).  It may not be worthwhile to resolve this rift, and we should 
allow disparate families of specifications to bloom, taking care not to 
cause developer confusion with naming (a hard problem).  Where 
specifications worked on in the DAP WG lend themselves to implementation 
plans, I think Mozilla participants interested in these can comment on 
them (e.g. Contacts API, at least for now).

-- A*
Received on Tuesday, 15 June 2010 23:32:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:44 UTC