- From: Arun Ranganathan <arun@mozilla.com>
- Date: Tue, 15 Jun 2010 16:32:17 -0700
- 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>
Bryan, 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