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

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.
>> > >
>> > >
>> > >
>> > >
>>
>
>