[webkit-dev] Implementing the <device> element

[Leandro Graciá Gil]

Hi,

We have recently noticed a patch to implement the <device> element in
WebKit. Since this is an important new feature, I thought we should have a
discussion about the best way to implement it. Here's the actual
specification for it:
http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices
 .

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.

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.

Here's an example of the call flow in our proposal:

0. The device element is created in a no connection state and with an empty
device connection descriptor.
1. User clicks the device element (a button, for example).
2. The device element changes its internal state from no connection to
connecting, and asks to the device controller to connect to a device of its
type sending also the document security origin.
3. The device controller, which handles and maps all the device requests of
the page, forwards the connection request to the device page client. This
client is implemented by the corresponding WebKit platforms.
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.

5. When the platform has finished connecting to a device, it sends back to
the device controller a device connection update message. This message comes
with a device connection descriptor that contains the actual connection
status, error codes/messages, device ids/names if connected and so on. In
case of user cancelation, connection or communication error the same message
is sent, but with different device connection descriptor values.
6. The device controller forwards the message to the original device
element. The original element sets its connection descriptor to the received
object and changes its state accordingly. It will change to connected if the
connection was successful or to not connected in case of error. It will also
fire the appropriate JS events.
7. If the connection was successful, the element will then create valid
stream objects from its data attribute. These will not contain any real
streaming data but just a url string. All the actual data is internally
managed by the platforms, leaving only handler-like objects in WebCore. The
url can be provided for the moment with the connection descriptor object,
being later replaced by some type-independent object when device types other
than media are defined.

Requesting to disconnect the device would work much like requesting a
connection, but providing the device descriptor object as a parameter
instead.

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.

I have a patch that implements this design, but I wanted to get some
feedback on this list before sending it out for review.

Please don't hesitate to make any suggestions that could help to improve
this.

Thanks,
Leandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110201/4984f520/attachment.html>