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

RE: Transferring File* to WebApps - redux

From: SULLIVAN, BRYAN L (ATTCINW) <BS3131@att.com>
Date: Tue, 15 Jun 2010 14:10:46 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD127BF609@BD01MSXMB015.US.Cingular.Net>
To: "Thomas Roessler" <tlr@w3.org>
Cc: "Robin Berjon" <robin@berjon.com>, <public-device-apis@w3.org>

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

Bryan Sullivan | AT&T

-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org] 
Sent: Tuesday, June 15, 2010 1:47 PM
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
> 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
> not believe that vision will be fulfilled if this work is transferred
> 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

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