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: Tue, 3 Nov 2009 17:20:03 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: Ian Hickson <ian@hixie.ch>, Arun Ranganathan <arun@mozilla.com>, "Web Applications Working Group WG" <public-webapps@w3.org>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB06253069@TK5EX14MBXC140.redmond.corp.microsoft.com>
On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
> 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:
> >> 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?).

There is a limit on the size of data-uris in IE8 (32K I think). I expect addressing this will be a higher priority than a new handler but I agree that copying around large strings is problematic.

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

Mostly in the implementation - it increases the surface area to be concerned about and there might be a different approach.

This isn't something I feel really strongly about. I imagine that when we look at implementing this we will start with just the API part and look at the URN handling separately.


Received on Tuesday, 3 November 2009 17:23:36 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC