W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: File API Feedback

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 19 Jun 2009 14:10:54 -0700
Message-ID: <63df84f0906191410j30008568u53b1421d73f7d71c@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: timeless <timeless@gmail.com>, arun@mozilla.com, Boris Zbarsky <bzbarsky@mit.edu>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
On Thu, Jun 18, 2009 at 8:30 PM, Ian Hickson<ian@hixie.ch> wrote:
> On Fri, 19 Jun 2009, timeless wrote:
>> On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathan<arun@mozilla.com> wrote:
>> > Hixie, I think a Base64 representation of the file resource may be
>> > sufficient, particularly for the image use case (which is how it is used
>> > already).  Can you flesh out why the new schema is a good idea?
>> so. I have folders with 100-1000mb of pictures in them. If I decide that
>> I want to upload them all (Picasa style), i'd expect it would take a
>> very long time to convert each file name into a base64 url.
> This is exactly the use case I had in mind, yes. data: URLs are fine for
> testing and prototyping, but as a practical matter, they don't really
> scale to real-world needs. For example, imagine a user uploading a local
> video (~1GB) to YouTube, where the page wants to show the video in a
> <video> element as (or immediately before) the user is uploading it (e.g.
> so the user can set the times where ads should show). A data: URL is
> clearly not an option here, I think.

As many others have pointed out, I think the data:-url solution only
scales so far. Once we start getting into video as well as very
high-quality images, we need a better solution.

However I'm not convinced that this solution needs to go into this
spec, or needs to go into version 1 of this spec. It seems to me that
for the case when you have a 1Gb video that is being uploaded to
flickr, or 100-1000mb of pictures being uploaded to Picasa, do you
really need to get any type of url to it? Sending the file using
XMLHttpRequest to the server should simply be a matter of passing the
File object to XMLHttpRequest.send. Yes, it would definitely be nice
if you could display a preview of the file no matter how big the file
was, but it seems like we can get very far without it.

That said. If anyone comes up with a suggested draft for scheme:uuid,
(including if Arun does so), I'd be all for putting it in the spec.

The problems that seems like they need to be solved are security (are
these URIs accessible by any domain), and lifetime (how long does the
URI work).

/ Jonas
Received on Friday, 19 June 2009 21:11:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC