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

On Mon, Oct 20, 2014 at 2:04 PM, mark a. foltz <mfoltz@google.com> wrote:
> [+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.

Yup. Sounds good.

/ Jonas

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

Received on Monday, 20 October 2014 23:17:49 UTC