W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Request for FPWD publication of Server-Sent Events, Web Sockets API, Web Storage, and Web Workers

From: Marcos Caceres <marcosc@opera.com>
Date: Thu, 2 Apr 2009 16:46:19 +0200
Message-ID: <b21a10670904020746sc2265a9v989483d0a686edbc@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-webapps@w3.org
Hi Ian,

On Thu, Apr 2, 2009 at 12:22 AM, Ian Hickson <ian@hixie.ch> wrote:
>   Web Storage
>   http://dev.w3.org/html5/webstorage/

The Web App's Widgets arm would like to discuss the possibility for a
UA to have some items in the Storage interface to be read-only.

We have two dependencies on Storage: the <preference> element in our
packaging spec and the API and Event's spec (which makes it required
for widget user agents to support Storage). The intended use of  the
<preference> element is to pre-populate a Storage object with keys and
values when a widget is first run. The preference element allows for
some preferences to be read-only (meaning that they cannot be cleared
or changed). E.g.,

   <preference name    = "skin" value="alien"/>
   <preference name    = "api-key"
               value             = "aa6a6d7a667a6"
               readonly        = "true" />

We envision scenarios where an author could set, for instance, a read
only token into the widget's configuration document that would
facilitate certain online and offline activities (e.g., a serial
number, or an authentication token to allow the author to log into the
widget without being online). As widgets can be digitally signed, this
would protect that values of <preference> from being changed in the
configuration document. Does that sound like a reasonable use case?

If you think it is possible to have read only Storage values,
naturally we would need some kind of access violation exception to be
thrown when someone tries to change a read only value...

Anyway, we would like to hear your thoughts.

Kind regards,

Marcos Caceres
Received on Thursday, 2 April 2009 14:47:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC