W3C home > Mailing lists > Public > public-webscreens@w3.org > August 2014

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

From: Francois Daoust <fd@w3.org>
Date: Wed, 20 Aug 2014 13:09:00 +0200
Message-ID: <53F481CC.6060901@w3.org>
To: "mark a. foltz" <mfoltz@google.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>
CC: Anton Vayvod <avayvod@google.com>, Jonas Sicking <jonas@sicking.cc>, Marco Chen <mchen@mozilla.com>, Wesley Johnston <wjohnston@mozilla.com>, Evelyn Hung <ehung@mozilla.com>
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 Wednesday, 20 August 2014 11:09:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:57:21 UTC