- From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
- Date: Tue, 15 Jun 2010 14:10:46 -0700
- To: "Thomas Roessler" <tlr@w3.org>
- Cc: "Robin Berjon" <robin@berjon.com>, <public-device-apis@w3.org>
Thomas, It's not entirely a technical question, but where can the work get more effectively done per the requirements. My preference is to keep these discussions in DAP as that's where we have regular F2F meetings and conf calls (which are important) and can address this functionality more consistently with the other DAP APIs. Adding another set of conf calls and potentially distinct F2F meetings is problematic re resources that can be applied to this work. But for the requirements, which in the current versions of the DAP APIs (Filesystem: File writing, Filesystem: other operations) are not far from where they need to be, and further input from me and others would definitely help, I understand: - access filesystems on the host device - traverse directories - 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 - write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options - do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) - provide security for this using the policy-framework approach as being defined for DAP APIs Thanks, Bryan Sullivan | AT&T -----Original Message----- From: Thomas Roessler [mailto:tlr@w3.org] Sent: Tuesday, June 15, 2010 1:47 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Thomas Roessler; Robin Berjon; public-device-apis@w3.org Subject: Re: Transferring File* to WebApps - redux On 15 Jun 2010, at 22:15, 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. Bryan, it would be helpful if you could re-state this in terms of technical requirements.
Received on Tuesday, 15 June 2010 21:12:30 UTC