Re: Feedback on Pull Request - RE: Session cancellation and reconnection

On Wed, Sep 17, 2014 at 12:45 PM, Rottsches, Dominik
<dominik.rottsches@intel.com> wrote:
> Hi MarkFo, Jonas, Anton,
>
> thanks for the pull request, I agree it's good to have the distinction between join and startSession. Also, it's good to start the algorithms sections.
>
>> The outcome of this sub-thread was a proposal made by Anton and Jonas
>> that would make the interface look like the following:
>> partial interface NavigatorPresentation {
>>   Promise<PresentationSession> startSession(
>>      DOMString url, DOMString sessionId);
>>  Promise<PresentationSession> joinSession(
>>      DOMString url, DOMString sessionId);
>> }
>
>> Note, also, that the mozilla-dev@ thread expressing intent to implement
>> uses the start/join flavor of the API (without Promises);
>
> Before merging, I would like to briefly revisit the questions of the return type here.
>
> Looking at the new example code (thanks for updating it!) - mixing Promises and the onstatechange event on the PresentationSession looks perhaps a bit more complicated than it needs to be. The steps of how a PresentationSession gets connected and usable are now spread across a Promise and the onstatechange handler, the developer using our API has to track both.
>
> Would it be more consistent to just return a session object, for which we could define an additional - for example - "Idle" state, or use the "Disconnected" state as well, then transition that to "Connected". This would still allow showing the user selection dialog asynchronously, and we would not need to map the transitions to Promise-resolution and PresentationSession state separately? If that sounds okay to you, I am happy to edit and update the pull request in this regard.
>
> One particular overlap/redundancy I see for example: When the Promise is resolved successfully from startSession or joinSession, is the session object is immediately in "connected" state? So the only transition on the onstatechange handler we would ever see is the one from "connected" to "disconnected"?

This is a very good question. To answer your last question first, in
the current design, I definitely think that when the Promise resolves,
that the returned PresentationSession should be in the "connected"
state.

However even then, the page has to deal with transitioning in and out
of a "disconnected" state. Which means that it still has to listen to
events. And so, like you point out, we still get the problem of having
to deal both with promises and events.

I'm still inclined to feel like the current API is the better one
though. I feel like you generally want to do quite different things
when the promise first resolves, and when you're handling other state
transitions.

When the promise first resolves, you'll want to display UI for
interacting with the presentation. This UI can then switch to some
form of "reconnecting" UI if the "disconnected" event fires, and then
back to the normal UI if the "connected" event fires again.

Another way to think of it is that the the first thing that happens is
that the startSession/joinSession call can succeed or fail. But even
if it succeeds and we have an established network connection that
connection can cut in and out. By only returning a PresentationSession
once we've established a connection, that makes that separation more
clear.

I.e. it's more clear that you can't start .send()ing data until you
have a connected session since there simply is no object to call
.send() on.

But these things are clearly just matter of taste. Both solutions are
technically equivalent and just differ in syntax. I.e. writing a
wrapper that converts in either direction is pretty easy. So I
definitely understand if other people come to different conclusions
than me.

And I'm somewhat biased since I've been beat over the head in the past
for creating APIs that relied too heavily on Events rather than used
Promises.

Another thing that might throw a wrench in this is that TC39 is
looking at observervables. That might very well change which approach
makes for most convenient code.

What ultimately matters here is which solution makes for the most
convenient code. We should ask developers and people that are more
used to state of the art JS API design (i.e. library authors) what
they think. I'm happy to take an action item to do that.

/ Jonas

Received on Monday, 13 October 2014 06:43:51 UTC