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

[+cc public-secondscreen@w3.org]

Hello,

I see there are good points to be made for the event-based and the Promises
model.  And Dominic should certainly be a good resource on the appropriate
use of Promises.

I can take the following item to move this forward:

- Draft a working version of the API with Promises to see if it is
ergonomic from the developer's point of view.

m.



On Mon, Oct 13, 2014 at 7:47 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Oct 13, 2014 at 1:35 AM, Rottsches, Dominik
> <dominik.rottsches@intel.com> wrote:
> > Hi Jonas,
> >
> > thanks for taking the time and your explanations. Sounds reasonable to
> > me.
> >
> >> 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.
> >
> > Alright, we should learn from your experience.
>
> I don't want to say that my experiences are directly applicable here.
> The situation was definitely different. I just wanted to acknowledge
> my bias :)
>
> >> 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.
> >
> > Could you elaborate a bit here where you see implications for our API
> > design?
>
> Observables are designed for when you have "streams of state changes".
> This should hopefully do for async state changes what Promises did for
> async return values.
>
> I.e. it might make it as convenient to listen to such state changes as
> to listen to a Promise.
>
> >> 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.
> >
> > If you could get some feedback from such developers within a short time
> > frame, that would certainly be useful, so that we can incorporate that
> > and close the issue.
>
> I did some outreach to Dominic Denicola Yehuda Katz, it seems like the
> preferred approach is to return a  Promise<PresentationSession>. The
> reason is that the first state transition is somewhat different.
> Especially if we ever start providing meta-data about the second
> screen once we first connect. That is easy to stick on
> PresentationSession with the Promise approach, but gets a bit awkward
> if we synchronously return a PresentationSession.
>
> This design is quite similar to the fetch() API [1]. Fetch returns a
> Promise<Response>, where Response represents an asynchronous stream of
> data. But the Response object also contains some synchronous metadata
> about the connection.
>
> But even without metadata, the fact that during the first state
> transition you'll likely want to display UI once a connection is
> established. Which also means that you'll need to remove that UI if
> the connection is permanently lost, but not if connection failed.
>
> At least this as been my assumption regarding the UI.
>
> I do however think that this is a relatively minor change in API. We
> can always change it later if we decide that synchronously returning a
> PresentationSession is better.
>
> [1] https://fetch.spec.whatwg.org/#fetch-api
>
> / Jonas
>