- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 20 Mar 2012 13:29:28 +0100
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 03/16/2012 10:59 PM, Anant Narayanan wrote: > On Mar 15, 2012, at 12:48 PM, Travis Leithead wrote: >> * I'm not comfortable overloading the src property. This opens the >> door to a lot of weird discrepancies between content attribute src >> and IDL attribute src. I don't want to open the door to >> URL-accepting properties becoming extensible by other arbitrary >> specs. I think File API established the convention for this >> extensibility by creating the blob: protocol. > > If we decide to go ahead with URLS we have to deal with the > portability of strings. For instance, what happens if the web page > passes the URL to another web site, which the user then opens in a > different tab, where a video.src assignment is made? > > URLs now have to be tied to the origin to which they were issued and > the UA must enforce this. This is not a problem with URLs as they > exist today as possession of the URL implies access to the data (and > in the case of blob: the URL itself contains the data). This is not > true for MediaStreams - MediaStreams are transient, issued to only a > certain origin, and perhaps even just a tab. If I read the File API spec correctly ([1]), the URL created by "createObjectURL" would only be usable in the origin where it was created. I wonder if MediaStreams are really so different from blob's/file's (or Streams) that it would make sense to define another way. createObjectURL is after all an established and expected pattern, it seems natural to me to extend it to MediaStreams. [1] http://www.w3.org/TR/FileAPI/#originOfBlob Translating these > requirements to a URL feels rather clunky to me, and are best > represented as objects (that are not by their very nature, > portable). > >> Specifying the "streaming behavior" as is noted in [5] is very >> important; I strongly support that, and I think it needs to happen >> irrespective of whichever "binding" approach is used for media >> elements. > > +1. roc's proposal for MediaStreamProcessing > (https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html) > has ideas in similar vein. > > -Anant
Received on Tuesday, 20 March 2012 12:29:59 UTC