RE: Transferring File* to WebApps - redux

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:37 UTC