Re: HTML Slidy remote - a Presentation API demo

On 2014-08-22 14:38, Kostiainen, Anssi wrote:
> 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)?

So, that addresses the issue for gathering the PresentationSession 
object in the presenting page. But that doesn't tell me when user agents 
will consider that the communication channel is established, so I think 
we may have the same issue with the "message" event.

Typically, depending on when the communication channel is considered 
established, the presenting page can still miss the first few messages 
sent by the controlling page. For instance, if the following occurs in 
order:

1. the controlling page calls requestSession
2. the presenting user agent starts to load the presenting page
3. the presenting user agent sets "navigator.presentation.session" and 
sets document readiness to "interactive"
4. the presenting user agent starts to run scripts of the presenting 
page. Let's say these scripts start by initializing an IndexedDB 
instance (an asynchronous operation)
5. the presenting user agent reports to the controlling user agent that 
the communication channel is ready
6. the controlling page calls "session.postMessage()" to send a message 
to the presenting page.
7. the presenting page calls "navigator.presentation.session.onmessage = 
function (event) {};" once the IndexedDB is done initializing.

... the message sent by the controlling page in 6. is lost in that case. 
In an ideal world, step 5 would only occur after step 7. but there is no 
way for a Web app to signal that it is really done loading. Or is there?

I'm not sure I have good solution in mind here. On top of my head, main 
possibilities are:

a) have the presenting user agent queue the first "message" events it 
receives until they can be delivered, with some timeout mechanism to 
drop the messages after some time.

b) force the presenting page to call a specific API function once it's 
ready to receive messages. The communication channel will be considered 
established only after that API function is called. It seems easy to 
forget issuing the call on the presenting side though, which would 
effectively make the presentation loop forever (or until some timeout 
occurs).

c) do nothing and warn developers that the presenting page would need to 
start listening to "message" events right after "DOMContentLoaded" to be 
sure to catch all messages from the controlling page. Alternatively, the 
presenting page could agree to share its readiness status with the 
controlling page as part of their proprietary communication protocol. 
For instance, the presenting page could send a "I'm ready" message to 
the controlling page that the controlling page waits upon before it 
starts sending messages.

Any other option?

Essentially, I'd like to ensure that the controlling page can be 
confident that its messages will be delivered and processed by the 
presenting page when the presentation session state is "connected".

Francois.

>
>> 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 13:48:19 UTC