On Friday, June 11, 2010 7:22 AM, Robin Berjon wrote: > On Jun 11, 2010, at 15:43 , Adrian Bateman wrote: > > 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?
That might be one approach. I wondered whether the proposal here was a single unifying scheme for all future uses of Blob without necessarily knowing whether that would work or whether each spec that consumes the Blob interface could express an approach (which could be the same as the File one). > 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. These are good reasons and I'm really just thinking out loud. I've seen some discussions about how live webcam capture might use this interface to provide a URL for the video feed that you could potentially assign to a <video> src attribute. I'm not sure if this is just an abuse of something that's not really a Blob but might the script want to be able to check if it's getting a video? Perhaps the URL could have a content type in a similar fashion to data:. Cheers, Adrian.
