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

Perhaps device motion/orientation should always return the
orientation/motion of the screen on which the presentation is shown
(whether or not rendering is happening remotely), and be unavailable if the
orientation/motion of that screen is unknown.

Then in both the 1UA and 2UA cases, if you want to e.g. use the controlling
device as a steering wheel, in both cases you would listen for
motion/orientation events in the controlling page, and send them via
postMessage to the renderer that is presenting.


On 21 August 2014 17:38, Bassbouss, Louay <
louay.bassbouss@fokus.fraunhofer.de> wrote:

>  Since there is no  distinction between the 1UA and 2UAs case on API
> level, it will be hard even impossible for developers to know which device
> API is used (on which device).
>
>
>
> louay
>
>
>
> *From:* Anton Vayvod [mailto:avayvod@google.com]
> *Sent:* Donnerstag, 21. August 2014 18:33
> *To:* Mark Watson
> *Cc:* Bassbouss, Louay; Jonas Sicking; mark a. foltz; John Mellor;
> 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)
>
>
>
> 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.
>
>
>
> 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.
> > >
> > >
> > >
> > >
>
>
>
>
>
>
>