- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 21 May 2014 08:40:11 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 21 May 2014 06:49, Harald Alvestrand <harald@alvestrand.no> wrote:
> On 05/21/2014 09:29 AM, Adam Bergkvist wrote:
>> On 2014-05-19 20:08, Martin Thomson wrote:
>>> On 19 May 2014 09:24, Stefan Håkansson LK
>>> <stefan.lk.hakansson@ericsson.com> wrote:
>>>> On 2014-05-18 20:47, Harald Alvestrand wrote:
>>>>> I'd like to have a real good story for why it shouldn't be an event
>>>>> fired at some object before introducing a third pattern in this API.
>>>>
>>>> The story would be precedence - watchPosition works this way. I don't
>>>> know if that is a real good story or not!
>>>
>>> watchPosition sets a bad precedent. I prefer using events.
>>>
>>
>> I would prefer an event as well. The question is what object should be
>> the corresponding EventTarget.
>>
>> I don't see that FF or Chrome have the
>> navigator.<prefix>getMediaDevices() function yet. It would be nice to
>> have some object on navigator where we could isolate our new stuff
>> which also could be our EventTarget.
>>
>> navigator.userMedia.getMediaDevices(...);
>>
>> navigator.userMedia.ondevice = function (evt) { ... };
>
> I like that. <bikeshed>Perhaps call it deviceManager?</bikeshed>
>
> Can you flush it into a complete proposal (WebIDL)?
partial interface Navigator {
void getUserMedia(MediaConstraints c, Callback success, Callback
fail); // legacy cruft
attribute DeviceManager deviceManager;
};
interface DeviceManager {
attribute SupportedConstraints supportedConstraints;
void getUserMedia(MediaConstraints c, Callback success, Callback fail);
sequence<DeviceInfo> enumerateDevices(); // or whatever it's called
attribute EventHandler? ondevicechange;
};
Received on Wednesday, 21 May 2014 15:40:40 UTC