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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 2 Nov 2009 22:12:21 -0800
Message-ID: <63df84f0911022212o2cfe19d7k7d667914d9e7ebe5@mail.gmail.com>
To: Adrian Bateman <adrianba@microsoft.com>
Cc: Ian Hickson <ian@hixie.ch>, Arun Ranganathan <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman <adrianba@microsoft.com> wrote:
> 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).

I'd really like to try to keep it in version 1. One of the use cases
we hear most often for this API is for uploading images. For example
to photo management sites like Flickr, but also for profile pictures
on sites like twitter. In both these cases it's possible to use
data-uris, but that will most likely result in the several copies of a
several-MB-sized data-uris living in memory. I think the situation
might be even worse in IE which if recall correctly there's some
fairly low limits on how big data-uris can be (is this correct?).

Are you concerned about security bugs in the feature design or in the
implementation?

/ Jonas
Received on Tuesday, 3 November 2009 06:13:14 GMT

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