Hi,<div><br><div class="gmail_quote">El 10 de febrero de 2011 15:15, Adam Bergkvist <span dir="ltr"><<a href="mailto:adam.bergkvist@ericsson.com">adam.bergkvist@ericsson.com</a>></span> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<div class="im"><br>
On 2011-02-09 22:10, Leandro Graciá Gil wrote:<br>
> So, does that mean that a WebCore platform-independent code is going<br>
> to determine if a new device handler should be created? I think that<br>
> some UAs may like to, for example, keep a track of trusted pages for<br>
> specific types of devices to determine if such a handler should be<br>
> created. And that is not likely to be implemented in the same way by<br>
> all the different platforms even if they intend to perform a set of<br>
> basic common security steps. I completely agree with you that the<br>
> behaviour should be consistent across platforms, especially the<br>
> security and privacy aspects, but I don't think that forcing the<br>
> common code to use available device lists is the way to do it. If we<br>
> want a consistent behaviour we should ask for it in the specification<br>
> and leave the implementation specific details open, not the other way around.<br>
><br>
<br>
</div>Yes, the platform independent code in the device element will determine<br>
if a selection has been made, or altered, in the list of available devices<br>
Provided by the platform. Before passing it to the device element, the<br>
list can be filtered by the platform to exclude some entries for whatever<br>
reason. Selections can also be automatically applied without showing the<br>
Device selector based on, e.g., stored preferences. The device element<br>
will examine the list for selection changes to determine if a new device<br>
handler should be created (and a change event dispatched).<br>
<br>
Consider the following example:<br>
1. The user clicks the device element button and a list of devices is<br>
   presented.<br>
2. The user selects a webcam in the list and clicks OK.<br>
*A new Stream is created*<br>
3. The user once again clicks the device element button and the list<br>
   is presented with the webcam selected from before.<br>
4. The user clicks OK.<br>
*No new Stream is created*<br>
5. The user once again clicks the device element button and the list<br>
   is presented with the webcam selected from before.<br>
6. The user selects a microphone in the list and clicks OK.<br>
*A new Stream is created*<br>
<br>
This is the behavior that should be consistent between ports.<br></blockquote><div><br></div><meta charset="utf-8"><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">I agree that this behavior should be consisted between ports. However, we seem to be missing a case here: what happens if the user wants to revoke access to a device in the middle of a streaming session? We need to be able to allow this case for obvious privacy reasons.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">We need a way to let the UA maintain the lifetime of Stream objects. These can be killed by the UA at any point (perhaps due to user action or hardware failure), so we need to specify what happens to these objects in such a case. We also need to design our implementation in a way that can handle this situation.</span></font></div>
<div style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">As far as I know, and please correct me if I'm wrong, your proposed design doesn't provide the user a clear way to invalidate a stream if he wants to. The Stream's lifetime is something completely handled by the platform-specific client and with no presence at all in the common WebCore code. We think this should also be an essential part of the common behaviour across platforms.</div>
<div style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Because of this reason we would like to raise this discussion to the specification level in the whatwg list. We think that the expected behaviour for the device element is something that still needs to be discussed before facing any implementation-specific details.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "></span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
> One important point that a selection-based design misses is that<br>
> potentially many devices, if not all, will require exclusive access to<br>
> them. Let me give a example. We have two different pages with device<br>
> elements. First, a user selects some device (e.g. a microphone) in the<br>
> first page, but the page makes no use of it for the moment and hence<br>
> the real connection is not performed. Minutes later and without<br>
> closing the first page, the same user selects the same device from<br>
> before on the second device element (if you have only one microphone<br>
> and an average user this could be very easy to happen) but this page<br>
> also makes no use for it at that moment. What happens if for example<br>
> the first page starts making use of the device and causes the<br>
> connections on the second page to fail? This is almost for sure not<br>
> the behaviour that the user is expecting or wanting.<br>
><br>
<br>
</div>It will be up to the device handler API (e.g. Stream) and its potential<br>
consumers to handle any errors that may occur. Exclusiveness for certain<br>
types of devices being one type of error. Another error occurs when a<br>
peripheral device is disconnected while in use. Even if you have<br>
established a "connection" to the device via the device element,<br>
handling such an error in the device handler API is still required since<br>
it is not possible to revoke a device handler instance.<br></blockquote><div><br></div><meta charset="utf-8"><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">I think this impossibility to revoke a device handler instance is currently the essence of our main divergence point, and something that should be discussed in the specification.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "></span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
If we again take <input type=file> and the File API as a model, there you<br>
select a filename from a list and get a File object that represents the<br>
file. The file itself can be removed from disk but the File object still<br>
exists. When you then attempt to use a FileReader on the File it will fail.<br>
<br>
Regarding exclusiveness for Stream objects, we don't have that limitation<br>
in our implementation. It is possible to select the same webcam in several<br>
device elements.<br></blockquote><div><br></div><meta charset="utf-8"><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">It's not a limitation but a feature. We're not talking about restricting a webcam to a single device element, but about having the possibility to do so if required by the  device itself, the use case or by security reasons. We should keep in mind that unless the specification finally decides to implement only the media type we should design in a way that is potentially compatible with other devices and use cases.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "></span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
> Yes, you're right on this. I pointed out in my last email that I don't<br>
> think that there is any problem in having some platform specific code<br>
> in WebCore as long as any platform can choose to use it or to easily<br>
> delegate this task to its own WebKit implementation. Sorry if my<br>
> proposed class diagram mentioned communicating with WebKit as it's not<br>
> necessarily the case. We have already fixed this for the new diagrams.<br>
><br>
<br>
</div>Do you see anything in our implementation that could not be easily<br>
delegated? As I said before, I would be happy to make any changes that<br>
would be required to implement the platform specific parts for Chromium.<br></blockquote><div><br></div><meta charset="utf-8"><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">And we thank you for that, but before fixing any implementation details we think that the problem first needs to be discussed at the specification level.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "></span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
BR<br>
<font color="#888888">Adam<br>
</font></blockquote></div><br></div><div>Thanks,</div><div>Leandro</div><div><br></div><div>PS: I'm sorry but I'll be out of the office from tomorrow 16th February to the 22th (Feb. also). I won't be able to replay quickly to the emails. I'm very sorry for any inconveniences.</div>
<div><br></div>