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

Re: Updates to File API

From: Arun Ranganathan <arun@mozilla.com>
Date: Wed, 02 Jun 2010 17:26:31 -0700
Message-ID: <4C06F6B7.4070709@mozilla.com>
To: Jian Li <jianli@chromium.org>
CC: Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
On 6/2/10 5:06 PM, Jian Li wrote:
> Hi, Arun,
> I have one question regarding the scheme for Blob.url. The latest spec says
> that "The proposed URL scheme is filedata:. Mozilla already ships with
> moz-filedata:". Since the URL is now part of the Blob and it could be used
> to refer to both file data blob and binary data blob, should we consider
> making the scheme as "blobdata:" for better generalization? In addition,
> we're thinking it will probably be a good practice to encode the security
> origin in the blob URL scheme, like blobdata:
> http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make
> doing the security origin check easier when a page tries to access the blob
> url that is created in another process, under multi-process architecture.

This is a good suggestion.  I particularly like the idea of encoding the 
origin as part of the scheme.
> Indeed, the URL scheme seems to be more sort of implementation details.
> Different browser vendors can choose the appropriate scheme, like Mozilla
> ships with moz-filedata. How do you think?

Actually, I'm against leaving it totally up to implementations.  Sure, 
the spec. could simply state how the URL behaves without mentioning 
format much, but we identified in the past [1] that it was wise to 
specify things reliably, so that developers didn't rely on arbitrary 
behavior in one implementation and expect something similar in another.  
It's precisely that genre of underspecified behavior that got us in 
trouble before ;-)

-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html
Received on Thursday, 3 June 2010 00:27:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:08 UTC