Re: User agent context for rendering the presentation

On Sat, Aug 23, 2014 at 12:36 AM, Jonas Sicking <jonas@sicking.cc> wrote:

>
> On Aug 22, 2014 5:32 PM, "Mark Watson" <watsonm@netflix.com> wrote:
> > On Fri, Aug 22, 2014 at 4:48 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >> > It had been suggested that we mandate something like incognito mode,
> where
> >> > IndexedDB etc. are cleared on the presenting UA before the
> presentation page
> >> > is loaded. I'm objecting to mandating that, on the grounds described
> above.
> >> > Of course if we don't mandate it, then people would still be free to
> >> > implement it that way, but that would also be free to implement a UA
> with
> >> > persistent IndexedDB like on desktops/laptops and the latter would
> have
> >> > better UX in many cases (IMO).
> >>
> >> The incognito mode discussion was around the 1UA case. I.e. that when
> >> the presentation page runs on the controlling device, it's important
> >> that it doesn't have access to data from the controlling device.
> >
> >
> > I think this is too restrictive for the 1 UA case. Of course the
> presenting page should not have access to the IndexedDB data stored by the
> controlling page, but I see no reason why it should always start with an
> empty IndexedDB. Why can't it see the data it stored there last time it ran
> ?
>
> The assumption is that if there's an IndexedDB implementation on the TV,
> there is also a web rendering engine on the TV. In which case there's no
> reason to use the 1 UA solution.
>
> A device which has an IndexedDB database, and which enables remote devices
> to read/write to that database over the network, but is not able to render
> webpages, sounds very theoretical.
>
​I think we're getting wires crossed here. I didn't intent to refer to such
a case at all.

Let's forget about apps and TVs and just consider regular UAs (one or two
of them): All I am saying is that if the presenting page stores something
in IndexedDB, then next time that same presenting page is loaded on the
same UA it should be able to retrieve the stuff it stored in IndexedDB,
unless the user has cleared it, of course. It had been proposed that
IndexedDB is *always* cleared before a presenting page loads, and that's
what I'm reacting to.

As far as the controlling and presenting pages are concerned, they should
not be able to distinguish the 1-UA and the 2-UA cases.

I believe a consequence of this on UAs that support rendering both the
presenting and controlling pages (i.e. a UA that supports the 1-UA case or
a UA that supports both presenting and controlling sides of the 2-UA case)
is that IndexedDB needs to be scoped not just by origin but by the pair (
origin, presenting | controlling ).

> >> I'm ok with leaving the 2 UA case undefined for now. I.e. I'm ok with
> >> letting the spec leave it up to UAs to decide if the page which runs
> >> on TV will see data from the TV or not.
> >>
> >> I think the main hurdle to enabling using data from the TV will not be
> >> specification text. The main hurdle will be getting hardware vendors
> >> to support this. Any help here would be greatly appreciated.
> >
> > I think the TV vendors might reasonably expect the use-case of
> connecting to apps on the TV to be addressed before the use-case of
> connecting to a fully-fledged UA on the TV, since the former is already
> widely deployed.
>
> Sure. Though this is dramatically harder given that all existing hardware
> has very different capabilities, use different network protocols, and have
> different apps installed.
>
> But everyone I talk to is very interested in supporting this. Me included.
> I just haven't heard any ideas how.
>
​I think this is straightforward for the DIAL case, specifically. ​What I
imagine is that we will make additions to the DIAL specification which
describe how DIAL can be integrated with the Presentation API.

A UA that supports DIAL and the Presentation API will need to recognize
when the page requests presentation of a URL that can be rendered by a
registered DIAL application. The UA will ask any discovered DIAL displays
whether they support that application. If they do, then the device can be
offered to the user as a possible destination for the presentation and if
selected, the application will be launched using DIAL. A final piece is
that DIAL will need to enable the discovery or registration of the protocol
/ port for communication with the application. After that, it's up to the
controlling page and the application to work things out themselves.

There are a few ways we could do the above in DIAL, but that is out of
scope of this group.

The only implication for Presentation API is - as I have mentioned before -
a need to discover whether there are devices available that can render a
specific URL, so that the page can correctly hide the presentation icon in
the cases that there are devices visible, but none of them support the
specific URL the page wishes to present. This could be in the form of a
filter on the onavailablechange event, or a new checkSession() API which
would take the same parameters as requestSession() but would just return a
boolean: true if requestSession() would result in at least one device being
offered to the user, false if no devices would be offered to the user.

...Mark




> / Jonas
>