Re: HTML Slidy remote - a Presentation API demo

On Fri, Aug 22, 2014 at 3:16 PM, Francois Daoust <fd@w3.org> wrote:
>
> Hi Anton,
>
>
> On 2014-08-22 15:57, Anton Vayvod wrote:
>>
>> 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.
>
>
> True. I don't know why I was looking at something more complex than that.
I guess I've always considered the "disconnected" state to mean "the
presentation session is over", not "the presentation session is up and
running but the communication channel is not available".
>
> How can the controlling page know that the presenting session has been
closed in that model? If all it gets is a "disconnected" statechange event,
it won't know whether the presenting end has stopped listening to messages
temporarily or whether the presentation session has been closed for good.
Is it on purpose?

I guess there're two approaches here:
1) hide as much complexity of reconnecting/establishing session from the
web developers; the session is "connected" when the channel is ready to
receive messages from the page, the session is "disconnected" when the
session is over/broken, the session is still "connected" even if the UA is
trying to reconnect on the lower level and queues the messages to be
delivered if reconnect is successful
2) define more states for the presentation session, e.g. add "connecting"
state that means the communication channel is being (re)established

Given that we rely on the page to show some relevant UI (e.g. some
"connecting" animation between the time user selected the screen and the
presentation has started) and should probably avoid queuing messages by the
UA, I'd prefer the latter option as long as we keep it simple enough.

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