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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
