- From: Arun Ranganathan <arun@mozilla.com>
- Date: Mon, 28 Jun 2010 14:42:58 -0700
- To: David Levin <levin@google.com>
- CC: Adrian Bateman <adrianba@microsoft.com>, Jonas Sicking <jonas@sicking.cc>, Jian Li <jianli@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
- Message-ID: <4C291762.2090602@mozilla.com>
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*
Received on Monday, 28 June 2010 21:43:33 UTC