Re: User agent context for rendering the presentation (was: Re: Google/Mozilla Presentation API update)

On Thu, Aug 21, 2014 at 9:50 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>
>
> On Thu, Aug 21, 2014 at 9:32 AM, Anton Vayvod <avayvod@google.com> wrote:
>
>> Yes. I think that having local device APIs enabled for the 1-UA case is
>> not about being able to distinguish the two cases but about the presented
>> page being confused since it would get the data from the device it's
>> running on rather than the one where the user sees it. On one hand the
>> developer could then use the DeviceMotion directly on the presented page to
>> control the game, for example, but on the other hand it wouldn't work as it
>> is in the 2-UA case.
>>
>> I believe our goal is to make developers write code once for both 1-UA
>> and 2-UA cases so separation of the locally rendered presentation from the
>> device is vital.
>>
>
>  ​Ah, ok, I think I was confused because ​we are conflating discussion of
> two kinds of API. Of course, for APIs that provide access to physical
> device capabilities, in the presenting context those should connect to the
> remote device, if they work at all. This would mean that in the 1-UA case
> they probably don't work at all. However, one could imagine that if there
> was - say - an API for discovering physical device resolution, then even in
> the 1-UA case calling this in the presenting context would get the physical
> resolution of the remote display.
>

I think presentation window dimensions would be guaranteed to reflect the
rendering surface offered to the presentation, but they would not
necessarily be the same as the device rendering that surface.  For example,
the UA may create an offscreen surface at 1280x720 to render the
presentation and stream it to a TV that upscales it to 1920x1080.  It's
important that there's some independence, because the sending device only
be able to capture+encode+stream at lower resolutions.


>
> The other case that was mentioned was APIs like IndexedDB or other
> persistent stores and whether these should be provided at all and if yes,
> whether they should be empty on every load of the presenting page. I'm
> arguing that they should be available and that they should not be cleared.
> But a consequence of making the 1-UA and 2-UA cases indistinguishable is
> that the IndexedDB store seen by the www.example.com controlling page is
> distinct from the IndexedDB store seen by the www.example.com
> presentation page, even in the 1-UA case.
>

I can see the use for a persistent rendering context for presentations.
 End-user latency for starting the presentation is an important thing to
minimize, and the ability to cache resources or authentication data across
presentations will help.

I think this was discussed in a different offshoot of the thread, but it
might make sense to treat the persistent context as a separate browser
profile.  In Chromium, each profile gets its own settings, cookie jar,
local storage, HTTP cache, and extensions.

However, we would need to define the scope of this presentation-only
profile.  If all presentations originating from a browser share a single
profile, they could interact through storage APIs and cookies (presentation
on example1.com loads an iframe from example2.com).   We could:

1. Scope by presentation session (which minimizes the benefit of caching
resources across presentations)
2. Scope by the origin of the presented URL
3. Not scope them at all (i.e. one profile for all presentations) and make
it the Web developer's responsibility to handle any cross-site
interactions, similar to the regular Web today.

>From an implementation point of view #3 seems simplest but welcome to hear
other thoughts.

m.


> ...Mark
>
>
>
>>
>>
>> On Thu, Aug 21, 2014 at 5:12 PM, Mark Watson <watsonm@netflix.com> wrote:
>>
>>>
>>>
>>>
>>> On Thu, Aug 21, 2014 at 8:08 AM, Anton Vayvod <avayvod@google.com>
>>> wrote:
>>>
>>>> Hi Louay,
>>>>
>>>> I think that in the 2-UA case, whatever the remote UA has should be
>>>> enabled so that the presented page could use it. In the 1-UA case,
>>>> everything should be disabled by default allowing the UA to add whatever
>>>> information it has about the screen it's presenting on.
>>>>
>>>
>>> ​Surely the two cases should be indistinguishable from the pages point
>>> of view ?
>>>
>>> ...Mark​
>>>
>>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>
>>>> On Thu, Aug 21, 2014 at 3:49 PM, Bassbouss, Louay <
>>>> louay.bassbouss@fokus.fraunhofer.de> wrote:
>>>>
>>>>> Hi Jonas, I agree to not disable  every device API It is important for
>>>>> Multiscreen applications to have the same behavior independent from 1 or 2
>>>>> UAs. Which device API do you think it is important to keep it enabled for
>>>>> the presenting page?
>>>>>
>>>>> Regards,
>>>>> Louay
>>>>>
>>>>> > -----Original Message-----
>>>>> > From: Jonas Sicking [mailto:jonas@sicking.cc]
>>>>> > Sent: Mittwoch, 20. August 2014 23:43
>>>>> > To: Bassbouss, Louay
>>>>> > Cc: mark a. foltz; John Mellor; Anton Vayvod; Francois Daoust;
>>>>> public-
>>>>> > webscreens@w3.org; Marco Chen; Wesley Johnston; Evelyn Hung
>>>>> > Subject: Re: User agent context for rendering the presentation (was:
>>>>> Re:
>>>>> > Google/Mozilla Presentation API update)
>>>>> >
>>>>> > DeviceOrientation events is definitely a very interesting question.
>>>>> I would be
>>>>> > ok with disabling those when the presentation page is running "on the
>>>>> > device" rather than "on the TV". Though for the 2 UA case I think it
>>>>> would be
>>>>> > fine to expose the orientation of the "TV". Consider the case of
>>>>> displaying a
>>>>> > presentation on a tablet rather than a TV for example.
>>>>> >
>>>>> > So maybe rather than disabling DeviceOrientation, we should define
>>>>> that if
>>>>> > possible, the events should reflect the orientation of the device
>>>>> that the
>>>>> > presentation stuff. If it's not possible to get accurate information
>>>>> about that,
>>>>> > then disable the API.
>>>>> >
>>>>> > Though it would be good if things like the screen orientation API,
>>>>> and APIs for
>>>>> > getting window size, reflected the the orientation and size of the
>>>>> window on
>>>>> > the TV.
>>>>> >
>>>>> > I also don't think it's generally true that we should disable all
>>>>> device APIs. For
>>>>> > example I think we should expose any game controllers that are
>>>>> exposed to
>>>>> > whatever device the page runs on. If it runs "on the device" we
>>>>> expose
>>>>> > controllers connected to the device, if it runs "on the TV" we
>>>>> expose any
>>>>> > controllers connected to the TV. Pages are not going to come to
>>>>> depend on
>>>>> > game controllers being connected anyway.
>>>>> >
>>>>> > / Jonas
>>>>> >
>>>>> > On Wed, Aug 20, 2014 at 11:47 AM, Bassbouss, Louay
>>>>> > <louay.bassbouss@fokus.fraunhofer.de> wrote:
>>>>> > > Hi Mark, all,
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > Just returned from vacation and try to follow the discussion. What
>>>>> > > about Device APIs I think they should be also disabled in the
>>>>> presenting
>>>>> > page.
>>>>> > > Otherwise the behavior of the application will be not the same
>>>>> between
>>>>> > > 1UA and 2UAs. For example if DeviceOrientation is used in the
>>>>> > > presenting page in the 1UA case it works  fine but not for 2 UAs.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > Best regards,
>>>>> > >
>>>>> > > Louay
>>>>> > >
>>>>> > > From: mark a. foltz [mailto:mfoltz@google.com]
>>>>> > > Sent: Mittwoch, 20. August 2014 19:27
>>>>> > > To: John Mellor
>>>>> > > Cc: Anton Vayvod; Francois Daoust; public-webscreens@w3.org; Jonas
>>>>> > > Sicking; Marco Chen; Wesley Johnston; Evelyn Hung
>>>>> > > Subject: Re: User agent context for rendering the presentation
>>>>> (was: Re:
>>>>> > > Google/Mozilla Presentation API update)
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > Yes, that wording is better.  To be clear the presentation context
>>>>> > > should have access to all storage features, but the storage itself
>>>>> > > should behave as John describes.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Aug 20, 2014 at 6:15 AM, John Mellor <johnme@google.com>
>>>>> > wrote:
>>>>> > >
>>>>> > > Drive-by: perhaps it would be better to say that presentation
>>>>> content
>>>>> > > has access to all these features as usual, but they always start
>>>>> off
>>>>> > > empty (and are emptied at the end of the session), as if the
>>>>> > > presentation content were launched in its own incognito window.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > On 20 August 2014 13:47, Anton Vayvod <avayvod@google.com> wrote:
>>>>> > >
>>>>> > > Hi Francois!
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > The intent here wasn't to disable the feature for the presented
>>>>> page
>>>>> > > but to force the developers to only use the provided messaging
>>>>> channel
>>>>> > > between the presented and presenting pages. If the presented page
>>>>> > > relies on the presenting one to store something in the cache or
>>>>> > > IndexedDB for it, it can be implemented to work in the 1-UA case
>>>>> but
>>>>> > > not in the 2-UA case. The presented page should have access to
>>>>> these
>>>>> > > HTML features if the user agent running the presentation supports
>>>>> it.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > I think the wording for the above list should be clarified that
>>>>> > > there's "no access to cookies, local storage or IndexedDB
>>>>> instances in
>>>>> > > the browser context of the page that initiated the presentation".
>>>>> > >
>>>>> > > The same way as the same page loaded in a normal Chrome window and
>>>>> in
>>>>> > > an Incognito window will have no way of communicating with its
>>>>> > > instances through the use of cookies or storage APIs.
>>>>> > >
>>>>> > >
>>>>> > > Hope it helps,
>>>>> > >
>>>>> > > Anton.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > > On Wed, Aug 20, 2014 at 12:09 PM, Francois Daoust <fd@w3.org>
>>>>> wrote:
>>>>> > >>
>>>>> > >> Hi Mark, Jonas, Anton, et al.,
>>>>> > >>
>>>>> > >> I have a question on the need to restrict the access to certain
>>>>> > >> features for presentation content.
>>>>> > >>
>>>>> > >> On 2014-08-14 02:05, mark a. foltz wrote:
>>>>> > >> [...]
>>>>> > >>>
>>>>> > >>> 4. User agent context for rendering the presentation.
>>>>> > >>>
>>>>> > >>>
>>>>> > >>> If we intend the same presentation content to be rendered either
>>>>> in
>>>>> > >>> the same user agent or a remote user agent, we need to carefully
>>>>> > >>> define the rendering context so that the application doesn't get
>>>>> > >>> different behavior according to whether it is rendered remotely
>>>>> or
>>>>> > >>> locally.  In particular the presentation rendering context must
>>>>> have:
>>>>> > >>>
>>>>> > >>>
>>>>> > >>> - No access to cookies, local storage or IndexedDB instances
>>>>> > >>>
>>>>> > >>> - No access to HTTP cache
>>>>> > >>>
>>>>> > >>> - No access to pre-existing SharedWorkers
>>>>> > >>>
>>>>> > >>> - Extensions are debatable - some may be required for e.g. VPN or
>>>>> > >>> firewalls to work correctly
>>>>> > >>
>>>>> > >>
>>>>> > >> I understand the need to have the presentation rendering context
>>>>> > >> behave similarly whether it runs locally or remotely, but I don't
>>>>> see
>>>>> > >> the implications in terms of restricting access to the features
>>>>> mentioned
>>>>> > above.
>>>>> > >> For instance, I don't understand why having access to the local
>>>>> (or
>>>>> > >> remote) IndexedDB could pose a problem. A Web app that uses
>>>>> > IndexedDB
>>>>> > >> cannot assume that the database exists, has the right version, or
>>>>> is
>>>>> > >> not being used by another tab that shares the same origin at the
>>>>> same
>>>>> > >> time. How is running a presentation context locally or remotely
>>>>> any
>>>>> > different?
>>>>> > >>
>>>>> > >> Could you clarify why it matters? What issues are you trying to
>>>>> prevent?
>>>>> > >>
>>>>> > >> For example, in the AwesomeGame example that Jonas presented
>>>>> > >> elsewhere in the thread, it would make sense to me to have the
>>>>> "full
>>>>> > >> game" run on the TV set. If the game makes use of IndexedDB when
>>>>> it's
>>>>> > >> available, then not being able to use it on the TV set could
>>>>> > >> noticeably affect performances or available features.
>>>>> > >>
>>>>> > >> From a developer perspective, it would also mean that presentation
>>>>> > >> apps would not have the same powers as regular Web apps and would
>>>>> > >> need to be specifically tailored as presentation apps, which
>>>>> strikes
>>>>> > >> me as odd. I would rather expect to be able to take any Web app,
>>>>> even
>>>>> > >> one that does not degrade gracefully when e.g. IndexedDB is not
>>>>> > >> available, complete it to run within a presentation session, and
>>>>> be
>>>>> > >> confident that it will work in any environment that supports the
>>>>> > >> features that the app is using. Granted, it's always good
>>>>> practice to
>>>>> > >> degrade gracefully (or rather to enhance progressively) but it's
>>>>> not
>>>>> > >> a reason to make that practice a requirement, especially for
>>>>> features
>>>>> > >> that developers rightfully start to take for granted in most
>>>>> browser
>>>>> > environments.
>>>>> > >>
>>>>> > >> Thanks,
>>>>> > >> Francois.
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>>
>>>>
>>>>
>>>
>>
>