Re: HTML Slidy remote - a Presentation API demo

Hi Francois,

On 19 Aug 2014, at 19:42, Francois Daoust <fd@w3.org> wrote:

> On 2014-08-13 17:00, Kostiainen, Anssi wrote:

[...]

>> We'll need to take your feedback from this experiment as it surely will help us iron out the rough edges in the API. This is what I call dogfooding :-)
> 
> The main difficulty for me was getting the order of events right to establish the communication channel.

It seems as if the Google/Mozilla’s proposal addressed many (if not all?) of the issues you discovered.

> The "present" event needs to be fired before the communication channel is established, otherwise the presentation page can easily miss the first few messages from the controlling page.

If we drop the present event and make sure a PresentationSession object is exposed on the navigator.presentation.session on the presentation page when the current document readiness is set to “interactive” (that is, when the user agent stops parsing, spec’d in the “The end” section of HTML spec), have we addressed this issue (obviously, omitting much of the details here)?

> The code of the presentation page must also listen to the "present" event right away (as opposed to after some async operation, which could happen for instance if the code was to be put in a JS module loaded asynchronously with some module loader such as RequireJS), otherwise the "present" event could be missed.
> 
> The spec should clarify when the "present" event gets fired in the presentation page. No sooner than the tick that follows the "load" Window event? No sooner than the tick that follows the "DOMContentLoaded" event? Can implementations queue up the event up until it can be delivered? Or did I miss something? The "present" event is essential in the presentation page since it is the one that gives it the handler to the presentation session.

Considering the above, I guess this problem solves itself.

> The other part that was not as straightforward to implement was handling reconnection to existing presentation sessions, be it only to cancel the previous session. That feature makes the life of the developer a bit harder but is really useful in the end, and I see Mark, Jonas, Anton, et al. have concrete proposals in that area.

True, the recent proposal that adds an ID and onlyReconnect flag to the requestShow() seems to attempt to make session resuming easier. When we’ve updated the spec, it may be worthwhile exercise to update your excellent prototype and see if we’ve addressed the issues you found (and see if there are any new surprises).

I think maintaining the demos alongside with the spec has an added benefit that they servs as live examples. And examples are often lacking in specifications, but are still looked after by web developers who would like to contribute to emerging spec work, but may not be familiar with WebIDL and spec prose.

Thanks for the feedback!

-Anssi

Received on Friday, 22 August 2014 12:40:33 UTC