Re: Automatic session resumption

Hi Konstiainen et al,

are there any concerns with the proposal that I haven't addressed in my
previous reply? I'd like to proceed with the changes we proposed.

Thanks,
Anton.


On Thu, Apr 17, 2014 at 4:04 PM, Anton Vayvod <avayvod@google.com> wrote:
>
> Hi Konstiainen,
>
> Thanks for the prompt reply.
>
> My comments/questions are inline (hopefully removing the Gmail formatting
will make it readable):
>
>
>
> On Thu, Apr 17, 2014 at 10:46 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:
> >
> > Hi Anton, MarkFo, All,
> >
> > On 15 Apr 2014, at 10:56, Anton Vayvod <avayvod@google.com> wrote:
> >
> > > Dear community group members,
> > >
> > > We would like to propose adding a way for the page to automatically
reconnect to a session running on a second UA, without reprompting the user
for screen selection.
> >
> > Thanks for sharing your proposal with the group. I see how this would
make the common use case of user visiting her favourite site to share
content on the secondary screen more seamless process after the initial
permission granting and session establishment.
> >
> > I have couple of clarifying questions:
> >
> > * The use case you have in mind is to allow the session to persist so
that user’s consent is not required as long as the session is not
explicitly closed e.g. by invoking close() on the session. Correct?
>
>
> The use cases we have in mind are in the rationale section of the OP.
Basically, if the presenting website navigates within the origin or the
user opens the same-origin page in another tab/window, the session object
received from the requestShow() call is unavailable to the navigated page
or the second page. However the developer might want to provide a session
experience to the user: as long as the user navigates within the site,
there's some control over the session; if the user opens the same page in
another tab, the user still has control over the session from there.
>
>
> >
> >
> > * Should the user be able to disassociate the session through the UA
somehow (think evil.example.com establishes a session the user would like
to get rid of)?
>
>
> Yes, I believe this would certainly be a nice thing to have.
>
> >
> >
> > To illustrate this a bit, let’s take an example of getUserMedia
permissions on Chrome. When I click the padlock (https) or document (http)
icon on the left side of the location bar, I’ll get a list of permissions
for all feature regardless of whether the site uses them or not. For Media
(aka gUM) the following drop down list is presented by default:
> >
> > [ ] Always allow on this site
> > [ ] Always block on this site
> > [x] Use global default (ask|block)
> >
> > [Note that the "Always allow on this site” option is only present if
the content is served over https, a hint that the site is more trusted and
the setting can be persisted. Other browser vendors may use different
heuristics in figuring out whether the site is trusted or not.]
> >
> > This dialog presented by the UA allows the user to opt-out from (or
opt-in to) a feature at any time, which is good. Would there be something
similar for the user to disassociate sessions?
> >
> > Below further comments on the concrete proposal itself (assuming your
proposal is extending the group’s recent thinking represented at [1]).
> >
> > > IDL:
> > >
> > > partial interface Presentation {
> > >   PresentationSession[] activeSessions();
> > >   EventHandler onsessionchange;
> > > }
> >
> > s/Presentation/NavigatorPresentation/ I guess?
>
>
> Yes.
>
>
> >
> >
> > Do you think activeSessions() can return the list of
PresentationSession objects in a reasonable time so that you don’t block
the main thread? If there’s a possibility this takes longer than couple(?)
of milliseconds, it would be better to either use a callback or return a
Promise instead. Also making this asynchronous would allow some
implementations to optionally prompt the user if they wish to.
>
>
> We considered having a Promise but then there would be two async ways of
updating the state. What if onsessionchange event fires after the developer
gets the promise but before the success callback is called? In the split
browser-renderer architecture, the renderer would have to keep a copy of
the active sessions list for the origin and update it to be able to provide
activeSessions() in an async way.
>
>
> >
> >
> > > Code snippet:
> > >
> > > var mySession = null, myUrl = “www.example.com/receiver”;
> > >
> > > var found = presentation.activeSessions().some(function(session,
index, array) {
> > >   if (session.url == myUrl) { mySession = session; return true; }
> > >   return false;
> > > });
> >
> > > if (!found) {
> > >   // no active sessions, we'll either get a session from
requestShow() or from
> > >   // the onsessionchange event listener.
> > >   mySession = null;
> > > };
> >
> > The mySession variable was initialized to null, so this step is
redundant IIUC? That would further simplify the example.
>
>
> Agree. I used it to be more explicit. In the real example, the website
might need to update its UI to reflect the disconnected state, for example.
>
>
> >
> > > presentation.onsessionchange = function(e)  {
> > >   var session = e.session;
> > >   if (session == mySession) {
> > >     // got an update for the session started/joined from this page
> >
> > What would be the PresentationSessionState here? We may need to rework
the states (see the PresentationSession interface at [1]) for a better fit.
Feel free to propose a set of states that would work for your use case.
>
>
> I think 'connected'/'disconnected' is enough for onsessionchange. If we
need to check the session state before it's connected, we need some
'initializing' state probably. We might want to add some 'invalidated'
state to distinguish 'disconnected' by the origin or for some reason the
origin/user can't control like connection failure or something started its
own session with the same device, evicting our session this way. This
distinction might be important for the developers to show the appropriate
error message to the user.
>
>
> >
> >
> > >   } else {
> > >     // |session| isn’t a session this page has started/joined,
> > >     // use it or not - up to the page
> > >   }
> > > }
> > >
> > > Semantics:
> > >
> > > If the browser has previously connected to any session or multiple
sessions via |requestSession()| called from the same origin, e.g. '
http://example.com/sender', the |activeSessions()| array will contain the
list of the session objects that can be used immediately from the current
page.
> >
> > [From the implementation point of view, this would be exposing
something that the implementation keeps track of anyway to the web content.]
> >
> > > |onsessionchange| event will be fired about the state change of any
session started from the same origin as the current page.
> >
> > Am I correct in assuming a screen can have 0-1 active session and N
inactive sessions, where N is an implementation dependent limit, can be
zero as well?
>
> I don't think I understand. My assumption is that a second screen is has
a running session already or not. In both cases it's probably available to
start another session, invalidating the current one if it exists.
Potentially, I could think of multiple sessions per screen/device, e.g. one
session for audio and one for video (well, to present a fireplace from one
origin while playing music from another) but I think this is out of our
scope in the nearest future.
>
> What do you mean by inactive sessions?
>
> The presenting origin would only have active sessions that are the
sessions actually running on some screens (we use an array here to allow
presenting to more than one screen at a time) and once the session gets
into 'disconnected' state it essentially becomes useless.
>
>
> >
> > Assuming my above assertion is valid, then some pondering on the
current design, and how this fits in with that:
> >
> > A session is represented by a PresentationSession object. The
onsessionchange event fires when the state of the session changes.
> >
> > The onavailablechange fires when the screen state changes, but lives on
the PresentationSession object currently — this seems a bit odd now.
>
>
> Do you mean the onsessionchange event? I think it needs to live in the
NavigatorPresentation as it might be fired for any active session.
>
>
> >
> >
> > Does it make sense to carve out something like “PresentationScreen”
that represent the screen with its own states and handlers, to clearly
decouple it from PresentationSessions?
>
> I don't think this is necessary. Could you elaborate more on what
states/handlers you would add?
>
>
> >
> >
> > WDYT?
> >
> > We should aim for the simplest possible API that gets the stuff done,
so please let me know if this sounds like an unneeded abstraction to you :-)
> >
> > > Rationale:
> > > This permits a user to navigate a site (scoped by origin) while
controlling the same instance of the presentation session, without having
to interact with the browser to reconnect to the second screen each time.
> > >
> > > Limitations:
> > > |activeSessions()| and |onsessionchange| will only work for a session
that was started on the same browser from the same origin.  It will not
return sessions started by other browsers.
> > >
> > > We also want to add a way to disassociate an origin from a session,
which would prevent the session to be visible to the pages with the origin.
 This would be called e.g. when the user logged out from the site.
> >
> > Thanks for your proposal.
> >
> > All - I’d like to hear what others think about it before we spec it out
more completely.
> >
> > Thanks,
> >
> > -Anssi
> >
> > [1] https://www.w3.org/community/webscreens/wiki/API_Discussion#WebIDL