Re: Updates to File API

Hi Dave,


On 6/23/10 8:24 AM, David Levin wrote:
> On Tue, Jun 22, 2010 at 8:56 PM, Adrian Bateman 
> <adrianba@microsoft.com <mailto:adrianba@microsoft.com>> wrote:
>
>     On Tuesday, June 22, 2010 8:40 PM, David Levin wrote:
>     > I agree with you Adrian that it makes sense to let the user
>     agent figure
>     > out the optimal way of implementing origin and other checks.
>     >
>     > A logical step from that premise is that the choice/format of the
>     > namespace specific string should be left up to the UA as embedding
>     > information in there may be the optimal way for some UA's of
>     implementing
>     > said checks, and it sounds like other UAs may not want to do that.
>
>     Robin outlined why that would be a problem [1]. My original
>     feeling was that this should be left up to UAs, as you say, but
>     I've been convinced that doing so is a race to the most complex
>     URL scheme.
>
>
> Robin discussed something that could possibly in 
> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html. At 
> the same time, there are implementors who gave specific reasons 
> why encoding certain information (scheme, host, port) in the namespace 
> specific string (NSS) is useful to various UAs. No other information 
> has been requested, so theories adding more information seem premature.
>

> If the format must be specified, it seems reasonable to take both the 
> theoretical and practical issues into account.
>

I agree that both theoretical and practical issues should be taken into 
account.  While I was initially in favor of a uniform URL format for 
blob: URLs, after following this discussion I came up with:

http://dev.w3.org/2006/webapi/FileAPI/#url

This allows a few things that I think the WG has discussed as desirable:

1. The scheme consists of an opaque string, which I recommend is like 
UUID in its canonical form.  The scheme does not disallow the inclusion 
of origin information in the URL, though I personally think 
implementations could use "smart caching" and not necessarily use the 
scheme to store this information.

2. The scheme allows for fragment identifiers, which are applicable on a 
media-type basis to the Blob being accessed.

It was clear that a "one size fits all" wouldn't be desirable.  I think 
*generally speaking* the actual blob: URL is hidden from authors, who 
won't have cause to interact with format, and this is why I chose to 
specify this the way I have.

> Encoding that the security origin in the NSS isn't complex. If a 
> proposal is needed about how that can be done in a simple way, I'm 
> willing to supply one. Also, UAs that don't care about that 
> information are free to ignore it and don't need to parse it.
>

I think it might be useful to supply one, but my instinct is that this 
does not need to be part of the specification.

-- A*