[webkit-dev] Implementing the <device> element

[Leandro Graciá Gil]

I have created a patch to introduce compilation guards for the device
element implementation. These should be the same independently of the design
approach we decide to take while enabling us to propose more specific
patches later. Here's the link:
https://bugs.webkit.org/show_bug.cgi?id=53595

Thanks,
Leandro

El 1 de febrero de 2011 01:43, Leandro Graciá Gil <
leandrogracia at chromium.org> escribió:

> 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/20110202/e6b09427/attachment.html>