Re: HTML Slidy remote - a Presentation API demo

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 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
>>>
>>

Received on Friday, 22 August 2014 14:17:25 UTC