I got what you mean. Thanks for clarifying it. Do you plan to add the origin encoding into the spec? How about using more generic scheme name "blobdata:"?
Jian On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan <[email protected]> wrote: > 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 > >
