Linking open issues to GitHub (was: Re: Draft algorithms specification)

Hi Mark,

I created issues in GitHub accordingly.

On resumption of multiple sessions, you said:
>         Instead, if we would like to allow resumption of multiple
>         sessions that
>         share a URL+ID, then several changes would be required:
>            - The user agent would need to assign an internal unique
>         identifier to
>         each presentation (or to each screen) so it could track them using
>         something other than URL+ID.
>            - joinSession() would resolve to an array of
>         PresentationSessions in
>         case there were multiple matches.
>

I replied:
>     Perhaps we can leave that as an open issue for the time being and
>     focus on main use cases that involve presenting content on only one
>     second screen first.

I created issue #39 to keep track of this:
https://github.com/w3c/presentation-api/issues/39

[...]

On screen availability and multiple sessions, you said:
> There is nothing preventing a page from requesting multiple sessions
> now, although it doesn't have a way to force the user to select a
> second, unused screen (or to even know if there is an additional screen
> available).  You are correct that we would need to provide more
> visibility into the status of all screens to support this use case cleanly.
>
> Do you feel like we should incorporate this question into a new Github
> issue?

I created issue #40 and note that issue #1 raises the question of 
multi-screen support as well:
https://github.com/w3c/presentation-api/issues/40
https://github.com/w3c/presentation-api/issues/1


On the semantics of close(), you said:

> Has the semantics of close() been discussed in the CG or WG yet?  It
> could mean one of three things:
>
> (1) Disconnect this PresentationSession (and only this
> PresentationSession) from the presentation.
> (2) Disconnect all PresentationSessions known by this user agent from
> the presentation.
> (3) Request that the second screen cancel the presentation (and, if
> successful, will result in #2).
>
> We can go with (1), which is the most conservative approach, but doesn't
> give a page any way to actually stop a presentation itself.  Either the
> user agent would  provide a mechanism, or it could message the
> presentation document to call window.close().  I'm fine with that
> approach (it's consistent with the UX we have for Cast) but I'm curious
> to hear other thoughts.

All good points. For tracking purpose, I would say this is broadly 
captured under issue #35:
https://github.com/w3c/presentation-api/issues/35

Thanks,
Francois.

Received on Monday, 12 January 2015 11:04:50 UTC