- From: Robin Berjon <robin@berjon.com>
- Date: Fri, 11 Jun 2010 16:21:52 +0200
- To: Adrian Bateman <adrianba@microsoft.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
Hi, On Jun 11, 2010, at 15:43 , Adrian Bateman wrote: > On Wednesday, June 02, 2010 5:27 PM, Arun Ranganathan wrote: >> 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 > > Do you think the URL scheme should be specified for each use of Blob or more broadly? For example, Blob is used in the File Reader API but also possibly in the Capture API in a different way. It might be useful to be able to use a different scheme for these different purposes to help the user agent route requests to the appropriate handler. I'd like to make sure that I follow. Without putting words into your mouth, are you suggesting that if I obtain such a pointer from a file, I would get file-blob:DEADBEEF but if I got it from a capture it would be capture-blob:C00lDBABE? There are several reasons why I'm not in favour of that: - it exposes too much of the underlying implementation, presumably it's not the end of the world to have a single object proxying for various providers - it introduces a debauchery of new schemes, all of which then have to be not only specified by registered - more importantly: it's none of the author's business where I'm giving him my picture from. If he's asking to use capture but I tell my UA to override that and use a file instead, the script should have no way of finding out. -- Robin Berjon - http://berjon.com/
Received on Friday, 11 June 2010 14:22:31 UTC