W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

RE: [FileAPI] Latest Revision of Editor's Draft

From: Adrian Bateman <adrianba@microsoft.com>
Date: Mon, 2 Nov 2009 20:25:16 +0000
To: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>
CC: Arun Ranganathan <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB0624BFF6@TK5EX14MBXC140.redmond.corp.microsoft.com>
On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
> On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson <ian@hixie.ch> wrote:
> > I would like to see implementation feedback on this. I don't
> > understand
> > why we would want to assign semantics to urn:uuid: URLs that are so
> > specific -- that seems completely wrong. It also seems really awkward
> > from
> > an implementation perspective to forgo the normal extension mechanism
> > (schemes) and have implementations give special (and non-trivial)
> > semantics to a subset of another scheme. Why are we doing this?

> But like Arun, I suspect that this feature is the most controversial
> in the spec. Apple expressed concern about having a string represent a
> handle to a resource, and when we talked to Microsoft they briefly
> mentioned that they has concerns about this feature too, though I
> don't know specifically what their concerns were.

The main concern I had was whether the URN feature was a must have for v1 given Arun's desire that this be the simplest spec that we could then build on later. Implementing a new protocol handler is more complex than just supporting the API part, for us anyway.

I am also concerned about introducing new origin semantics - in the past this has been a source of security bugs and so I question whether we need to rush into this part (I accept the use case is valuable but I'm not sure it is initially essential).

Cheers,

Adrian.
Received on Monday, 2 November 2009 20:27:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:34 GMT