- From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
- Date: Tue, 15 Jun 2010 14:24:50 -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, 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?). 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. Thanks, Bryan Sullivan | AT&T -----Original Message----- From: Arun Ranganathan [mailto:arun@mozilla.com] Sent: Tuesday, June 15, 2010 1:48 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 1:15 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: > We would not be in favor of this transfer. We believe this API needs to > be developed in the DAP group, as our vision for its functionality was > driven by the input from BONDI and in general as a *device* API (as > compared to an abstracted API for cloud-based file resources), and we do > not believe that vision will be fulfilled if this work is transferred to > Webapps. > The BONDI API isn't a good starting place for an API that can be built into web browsers, since it doesn't gracefully layer into the existing HTML input element model for file selection. You are making a distinction I don't understand clearly, since we're not really considering "cloud-based file resources" with the FileReader API. Rather, we are considering file resources resident on the device. The API allows you to select them using an input element, and then access the file resource and programmatically manipulate it as a Blob. Similarly, the FileWriter API allows you to use the "save as" channel to write to the device in question. The FileSystem specification posits an abstraction that isn't necessarily "cloud-based" (although FWIW that is also possible). If you have a different vision, then that vision is incompatible with web browsers. In this case, I'd encourage the DAP WG, which *also* has a charter to work on file system deliverables, to construct an API which matches the use case you have in mind. You may then pursue the relevant BONDI API, which as a browser vendor I cannot consider. > If the issue is the level of discussion in this group, that can be > addressed. For one, I have seen quite a lot of traffic on the DAP email > list about this, so I don't understand the question of activity. > If you note the discussion on FileWriter, you'll see that the lion's share of feedback comes from cross-posts to public-webapps@w3.org. Feedback from others, including those that post to the DAP WG, is always welcome. > But to start, I will address some of the open topics in the current > draft on the DAP list, to help get the discussion moving faster. > > Again, I'd urge you to reconsider your position. The move of the specification in question -- FileWriter and FileSystem -- allows for greater collaboration on the same web stack, *and* allows parties that are NOT members of the DAP WG to comment on the technology. Perhaps you are misunderstanding the goals here? Or, perhaps you can provide a tighter definition of what you mean by "cloud-based file resources" *exactly*? DAP WG members are, by charter, free to consider technology that matches their particular use case. -- A*
Received on Tuesday, 15 June 2010 21:26:38 UTC