[webkit-dev] Implementing the <device> element

[Adam Bergkvist]

Hi,

Leandro Graciá Gil wrote:
> The approach proposed in https://bugs.webkit.org/show_bug.cgi?id=47264 
> brings the device probing and selection to the WebCore level. It does 
> so by first creating a list of available devices using an interface to 
> a platform-dependent client and then it passes this list to a client 
> dialog to perform the actual selection from it. With its current 
> design both operations are performed synchronously, possibly blocking 
> the device element event handler for a long time. I think this is not
> a suitable design.

The device selector dialog was never intended to block the event loop.
That was a mistake. In GTK the main loop continues to run when the dialog
is shown so although the click handler is blocked the event loop is not
blocked. We should not have expected this behavior on other platforms.
I have now added a callback from the dialog to the device element when a
selection has been made, making it possible to implement a completely
asynchronous dialog.
 
The interface towards the platform for getting a list of available
devices is called createDeviceList; it makes no assumption about how
the probing is done. The only assumption is that when a device selector
dialog is about to be presented to the user, a list of available devices
is needed. Typically, probing involves asking the OS kernel for a list of
available devices and this operation is usually fast. That's why we in our
GTK implementation have chosen to simply do the probing synchronously from
createDeviceList. I have now moved the createDeviceList call to device
dialog code. This makes it possible for platforms that want to do
on-demand probing but fear it might block, to call it off the main loop.
 
> Given the drawbacks of the approach above, I would like to propose an 
> alternative design that solves these issues.
> First of all, we think that is not necessary at all to bring the 
> device probing, available device lists, device selection or connection to WebCore.
> The device element isn't really about actual devices, but about 
> connecting to them. We think that it would be the best for all 
> platforms to actually delegate the actual probing, selection and 
> connecting to them in an asynchronous client-based model and hold only 
> connection and handler information in WebCore.
> 
The device element is about devices and specifically about selecting devices.
<device> is inspired by <input type=file> and so is our implementation. When
the change event should trigger on the device element, for example, is
something that will eventually be specced out and so the code that handles
this logic is best put in WebCore in order to preserve consistency between
ports.
 
> 4. The device client receives the request and, in a non-blocking way, 
> implements the way it likes the device probing, selection, connecting 
> and all the required security operations (the latter also missing in 
> the existing patch). This allows every UA vendor to make their own 
> choices about the UI for device selection.
 
Every vendor should be able to style the device selector as they want, but
the user experience should be coherent between platforms since <device> is
in its essence a security feature and user recognition is an important aspect
of that.
 
> With this approach, not only we avoid to block WebCore with 
> potentially long operations but we provide a great flexibility to all 
> WebKit platforms to implement the nasty device handling details as 
> they want to. This should also potentially increase the amount of code 
> that can be reused by the different platforms, while avoiding any list 
> matching code that can be found in the existing patch.
>

Can you please elaborate on how putting more code in the platforms, instead
of WebCore, will increase code reuse?

We would gladly make any changes that could make it easier for you to
implement the platform specific parts.

BR
Adam