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

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

Received on Thursday, 21 August 2014 14:50:26 UTC