Re: Transferring File* to WebApps - redux

On Tue, Jun 15, 2010 at 2:24 PM, SULLIVAN, BRYAN L (ATTCINW)
<BS3131@att.com> 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.

Hi Sullivan,

I certainly agree that browsers aren't the only web context or
use-case. However I strongly feel that we should design APIs for
browsers separately from APIs where the security model is different
from that of browsers.

For example in a browser it is unacceptable for the web page to read
the users file system without the user first granting access to this.
And even then there are likely restrictions as to prevent users from
getting hacked just because they clicked "yes" on a dialog they didn't
understand and just wanted to go away (aka the "whatever dialog"
problem).

On the flip side, it might make a lot of sense for a widget running on
a mobile phone, which some authority has authorized, to have read
access to large parts of the phones file system. And possibly even
write access to parts of it.

However these differences in security model will likely lead to
differences in API. This is ok. Lessons from the past, with for
example the DOM-Core spec, show that if we try to create an API that
fit too many different audiences (in that case it was both server-side
environments, as well as web pages). I would really like to avoid
repeating similar mistakes.

So my suggestion is that we let the FileWriter and File System APIs be
ones that are designed for the browser security model. And let them be
designed in the webapps WG which is already working on several very
similar features (for example I would argue that IndexedDB should
supersede File system).

If you or anyone else wants to design similar file related
specifications, but that has different security model or otherwise
different requirements than what exists in the web browser context,
then this in no way should impact you. If this should happen in DAP,
BONDI, or even in WebApps is a separate question which I basically
don't have much of an opinion on at all.

/ Jonas

Received on Tuesday, 15 June 2010 21:49:10 UTC