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:[email protected]]
Sent: Tuesday, June 15, 2010 1:48 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: Robin Berjon; [email protected]; 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 [email protected].
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*
