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

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.