On 13 November 2012 14:54, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> When you say “I am coming to the conclusion that createObjectURL() is no longer an entirely appropriate style of API for this use case; direct assignment is better”, are you intending that the direct assignment would clone the Track? However, the object passed to <audio> and<video> is a MediaStream, so we’d have to clone it as well as its tracks. And if we don’t clone them, I don’t see how this helps with the problem that you have identified.
Yes, cloning would have to apply to a MediaStream, and all its attached tracks.
> However, as a matter of style, I think it’s fishy/confusing if a bunch of our functions implicitly clone Tracks, while not cloning other objects. My model for this sort of problem is Lisp, where some functions operated on copies of their args, while others destructively modified them. But at least the Lisp naming conventions assigned different names to these two types of functions, so programmers would eventually figure it out.
I definitely don't want that, though that could be something we can
solve with good names. I definitely don't want direct assignment to
have bizarre and opaque side effects, even if that might be possible
in your language of choice.
> It might be clearer if we always passed the _Source_ as the argument, and then documented that the function created a new Track for the Source. On the other hand, it wouldn’t be clear what the settings for the new Track should be.
I don't think that we are able to expose sources in quite that
fashion. Unless we reach some new conclusions about the enumeration
of sources with respect to the fingerprinting problem.
> In short, I think that you have identified the a real problem, but I’m not sure that we have a clean solution yet.
Absolutely, I didn't want to imply that I had a good solution in mind.
I don't. (And I wouldn't want my half-baked ideas to be prejudicial
either.)