- From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
- Date: Tue, 15 Jun 2010 15:24:36 -0700
- To: <arun@mozilla.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>
Arun, 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 2) traverse directories 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 4) write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options 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 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. Thanks, Bryan Sullivan | AT&T -----Original Message----- From: Arun Ranganathan [mailto:arun@mozilla.com] Sent: Tuesday, June 15, 2010 2:53 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-apis@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > Arun, > > The basic concern I have is with the notion of "browsers" as the only > Web context and use-case that matters. The browser-based model for API > integration view (as I understand your position) is that the user must > be actively involved in every significant action, and choose explicitly > the actions that enable integration with browser-external resources > (including local and remote). Step back and you will see the > inconsistency in that (what would Ajax be if the user had to approved > every HTTP API request via an<input> element?). > In the case of the File API, I'm merely stating that the capability should be an evolution on top of what web pages already do with respect to the input element, and not introduce a new unbounded API space which doesn't consider user involvement, or reconsiders it with other consent models. Equating ajax with this in general isn't relevant to the argument. If you have no substantial technical differences with FileReader, FileWriter, and the FileSystem API, why are you blocking them from moving? What additional oversight does the DAP WG provide, that the WebApps WG does NOT provide? The WebApps WG has MORE browser vendors than the DAP WG, allowing review that's pertinent to the technology we are building. Below, you say: > Webapps are much more than just dynamic Web pages. They are > applications, and with HTML5 will have the ability to rival desktop > applications, as is clearly the vision of many in the industry. It might > even enable a return to a thin client world (e.g. browser as OS) in > which most significant resources are cloud-based. I see the logic and > value in that, but it's not the only valid (and valuable) model. > > W3C focuses on the Web, and the Web is bigger than the browser use-case. > HTML5 and the APIs that attach HTML-based applications to the world can > actually be the application platform for the next era of the Web, but > only if we do not limit the options to the user-centric/control > paradigms of the past. > But, by charter, the DAP WG allows you to address those very use cases! If the FileWriter, FileSystem, and FileReader specifications do NOT address the vision you articulate above, why not create a specification relevant to your use case? Naturally, browser vendors see value in technology that serves the cause of dynamic web pages. Why are you disallowing maximum browser vendor review by prohibiting a sensible move? Even within the DAP WG, feedback isn't as forthcoming on these specifications as it is in the WebApps WG. Please reconsider your stance here. You are not providing technical feedback on the specifications in question, nor illustrating why they don't address your use cases. But, you are blocking them from moving to a place where there *is* healthy technical feedback, worrying that those who *are* providing technical feedback will be poor custodians of a technology they are enthusiastic about building into their products. This is unfair. -- A*
Received on Tuesday, 15 June 2010 22:25:22 UTC