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

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 Tuesday, 14 October 2014 02:48:25 UTC