- From: Anton Vayvod <avayvod@google.com>
- Date: Thu, 21 Aug 2014 16:08:51 +0100
- To: "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>
- Cc: Jonas Sicking <jonas@sicking.cc>, "mark a. foltz" <mfoltz@google.com>, John Mellor <johnme@google.com>, Francois Daoust <fd@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Marco Chen <mchen@mozilla.com>, Wesley Johnston <wjohnston@mozilla.com>, Evelyn Hung <ehung@mozilla.com>
- Message-ID: <CAOjek6pWww57fYTcdCJwiVy8+TaaSyQ7Ne-LxNC=Xfco3hJ29g@mail.gmail.com>
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. 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. > > > > > > > > > > > > >
Received on Thursday, 21 August 2014 15:09:44 UTC