Re: Transferring File* to WebApps - redux

All,

I think this touches on almost everything, including the File* topic 
currently being discussed.. please, ask yourselves:

Why are why are developers building extensions to create client side 
applications? Are they not still running in the browsers? why have they 
been pushed outside of the main browser context?

Why are developers using 3rd party provided plugins in order to display 
a client side application in the main browser context? is everything 
they need to do not already provided by HTML5, ECMAScript and the 
various APIs being worked on?

Why do application developers for mobile devices have to work on device 
specific APIs? Does the combination of HTML5, ECMAScript and the various 
APIs being worked on not provide everything they need?

What is a widget? why the distinction? is this not just a client side 
application that is HTTP enabled? Why must a widget using HTML5 and 
ECMAScript be forced outside of the browser, outside of the main browser 
context, embedded within 'page'?

Why is it that we have a universal api that allows us to work with 
virtually any file in the world (HTTP), securely (HTTP+TLS), but need to 
define a new one to work with 'local' files?

Why do we define 'local', are our files not distributed between mobile 
devices, web servers, desktop machines and a plethora of other devices? 
Why is it suggested that when a user wants to <input> a file that the 
file must be located on the device they are currently working on?

Why do we consider the origin of a request as a path to privacy and 
security? Is the need not to provide a means to identify the person and 
the application making the request when required?

The web has been a revolution to humanity so far because it is free, and 
because it is based on the principal of universality. The hard work of 
the HTML5 and webapps working groups, combined with that of the vendors 
has provided almost everything needed for another layer of universality, 
a universal UX/UI interface (HTML5) and a universal language 
(ECMAScript) - both of these hide the vendor specific implementation 
while defining a universal interface - we care not what engine renders 
our HTML (/implements the DOM API), and we care not what engine runs our 
ECMAScript (or indeed whether it ultimately runs as native c/other).

Throughout the last decade 'web applications' have been pushed to the 
server side for multiple reasons, many of which can be discovered by 
thinking about the aforementioned questions, we have reached a point in 
history where many web applications, if not most, can easily be run on 
the client.

However, subtle misalignments with web architecture, differences in 
vision between specifications, and on a higher level focusing on the 
hacks of yesterday and the problems of today, working for the here and 
now rather than considering the ten year timeline; have all mounted up 
to a mismatched set of specifications which when combined will force 
applications back to the server side, and push developers towards 
extensions, plugins, widgets and vendor specific APIs.

I would urge you all to take a step back, remove yourself from the 
details and the problems of today for a short period, and think about 
where we all want to be - we are on the brink of a huge paradigm shift, 
a common vision and understanding of the web is emerging - the work you 
are all doing under the banner of these working groups is critical 
moving forwards, and repercussions of any mistakes made will be felt for 
many years to come.

To hopefully help, here is a short vision of something I would 
personally like to be able to do in the near future - if you find you'd 
like to do the same (or enable others to do so) then please do work 
together to make it possible one day:

I would like to create a web application in ECMAScript and HTML5, which 
I can package up in manner similar to a 'widget', sign it and include 
details on the domains or level of http access needed. I'd like to 
include the certificate from the key pair I used to sign the 
widget/code, and in that certificate I'd like to include an application 
identifier (in the form of an http URI). I'd like to deliver this 
application via HTTP.

I wouldn't expect the application to be 'installed' or saved on the 
client, rather cached (in the http sense) this way any time I upgrade 
the code it is automatically updated on the client, without the need for 
some convoluted update system (changes in access requested would 
hopefully be presented to the user and confirmed of course..).

When a user requests the application I'd like the user-agent to detect 
that it is a client side application, check the signature, and present 
the user with the identity of the application together with the details 
of HTTP access needed, if the user okay's this, then the application is 
run in the main context of the user-agent.

Interaction with data sources from the application would all be through 
ecmascript (xhr/xdr) and be RESTful in nature, these data sources would 
not be from the same origin (as I only made the app, not the data), 
rather it would pull from the web of data.

I would like the user to be able to <input> any files they liked, 
however these files would be exposed through HTTP and addressed with 
URIs, I care not for some file access api but would rather see the focus 
go in to exposing peoples resources through http.

I'd want any personally identifiable information to always be sent over 
secure channels [http+tls], and any sensitive resources to be accessed 
via http+tls, access to that resource should be determined by the 
server, but this can only be done if the person is also identified, thus 
a client side certificate with a unique identifier for the person would 
have to be presented in the http+tls session.

And finally, but most importantly, I'd like this application to run on 
any device and in any user-agent that supports html5 and ecmascript, 
after all, why shouldn't this be possible?

What we all need, and want, is just a way to create an application, wrap 
it up and know that whoever wants to can run it on whatever device (and 
in whatever ua) they please - this isn't a pipe dream, and everything 
needed already exists - it just needs pieced together and for you guys 
to adopt + promote.

Apologies for the length of the mail, but you know.. had to say it..

Best,

Nathan

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?).
> 
> 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 Wednesday, 16 June 2010 16:01:10 UTC