Re: HTML Slidy remote - a Presentation API demo

How about the UA fires onsessionstatechange event with state == "connected"
to the controlling page only once the presenting page subscribed to the
presentation.session.onmessage ? Before the session is in the "connected"
state all messages sent by the controlling page are lost.

I guess the same problem is relevant to the opposite direction of
communication. The presenting page should know if the controlling page is
listening to its presentation.session.onmessage event before sending the
messages.


On Fri, Aug 22, 2014 at 2:47 PM, Francois Daoust <fd@w3.org> wrote:
>
> 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
>>
>