W3C home > Mailing lists > Public > public-secondscreen@w3.org > August 2015

Re: Renaming 'join' to 'reconnect'

From: mark a. foltz <mfoltz@google.com>
Date: Tue, 25 Aug 2015 14:55:55 -0700
Message-ID: <CALgg+HEyfG1oud7dxtgSegck7Fh-gpwgtckzzzgQ7G2S2Qs=5Q@mail.gmail.com>
To: Anton Vayvod <avayvod@google.com>
Cc: Jonas Sicking <jonas@sicking.cc>, "public-secondscreen@w3.org" <public-secondscreen@w3.org>
On Mon, Aug 24, 2015 at 1:20 PM, Anton Vayvod <avayvod@google.com> wrote:

>
>
> On Mon, Aug 10, 2015 at 11:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Mon, Aug 10, 2015 at 1:56 PM, mark a. foltz <mfoltz@google.com> wrote:
>> >> It might be nice to make this more clear in the naming of the API.
>> >> Maybe by renaming 'join' to 'reconnect' or 'resume' or some such?
>> >
>> >
>> > I agree that join is not the best name.  Perhaps connect() covers use
>> cases
>> > #1-#3: since you can connect an additional controller, or reconnect
>> after
>> > navigation or restart.
>>
>
> I filed https://github.com/w3c/presentation-api/issues/170 to track the
> renaming of join() to connect().
>
>
>>
>> I think 'start()' vs. 'connect()' doesn't make their difference
>> entirely clear either. But I can certainly live with it and I agree
>> it's an improvement.
>>
>
> create() as in create a new connection vs. reusing an existing one when
> using connect()?
>

create()/start() is primarily for creating a new presentation.  But it's a
little ambiguous since we've also discussed allowing the user to connect to
an existing presentation (i.e. joining a game).

I commented in the issue, but what about:

request.show()           // If successful, guarantees that the URL is shown
and a connection will be created to it
request.reconnect(id) // Reconnects to the shown URL if possible

m.
Received on Tuesday, 25 August 2015 21:56:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 August 2015 21:56:44 UTC