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

Re: File API Feedback

From: Robin Berjon <robin@berjon.com>
Date: Fri, 19 Jun 2009 15:31:54 +0200
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>
Message-Id: <53C3DEEC-B094-43B2-BBEE-70C9158C2296@berjon.com>
To: Ian Hickson <ian@hixie.ch>
On Jun 19, 2009, at 05:30 , Ian Hickson 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.

It also doesn't scale to the (as yet hypothetical, but suggested  
multiple times) case in which the file input is used to point to a  
capturing device (e.g. a webcam). You do want to be able to point  
<video> at the stream, but I have reservations about a magical Base64  
string that would just keep growing :)

At the risk of opening one big bad can of worms, the use case for such  
a synthetic URI scheme seems reasonably close to that for widget URIs  
(we might have to wiggle around context-dependent semantics, which  
could get ugly). Perhaps we should mint a single scheme that would  
cover all runtime operational needs to synthesise a URI and use it  
across the board. After all, it's about being to reference something  
without using file:.

This of course can get interesting. We've looked at getting such a URI  
from image and video files and having <img> and <video> point to them,  
and there's no question it'd work fine for <audio>. I'd expect it to  
work with HTML files and <iframe>. What about getting said URI and  
linking to it with <a>?

Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Friday, 19 June 2009 13:32:28 UTC

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