ISSUE-17: Key Attributes - Proposed resolution

Based on the discussion over the past weeks, I'd like to propose a
resolution text for ISSUE-17.

Individual requests for comments from the people cc'd follows

Proposal:

Interface:
// Uses the Storage interface, from
http://www.w3.org/TR/webstorage/#the-storage-interface
// Given the concerns re: Storage, this may need to become an
IDBObjectStore, from http://www.w3.org/TR/IndexedDB/#object-store
interface KeyAttributes : Storage {
  // Note: I'm not sure if these overrides are necessary, but because
I'm changing behaviour, documenting it as such.
  // For the full set of methods, see the Storage interface, from
which this derives from.
  setter creator void setItem(DOMString key, DOMString value);
  deleter void removeItem(DOMString key);
};

Normative Text:
The KeyAttributes object provides origin-specific storage for extended
key attributes. Unlike existing name/value storage mechanisms
(WebStorage, IndexedDB), the duration of attribute storage is tied to
the lifetime of the Key. If the Key has been marked as temporary,
attributes that are set persist until the Key is removed at the
completion of the top-level browsing context. If the Key has been
marked as permanent, attributes will remain accessible until the Key
has been removed via KeyStorage.removeKey.

KeyAttributes may contain read-only name/value pairs. Such attributes
may be initialized during the provisioning of the Key object as part
of the generateKey(), importKey(), or deriveKey() operations.
Additionally, for user agents that support the pre-provisioning of
Keys using implementation-specific mechanisms, both read-only and
read-write attributes may also be provisioned using out-of-band,
implementation-specific mechanisms.

The setItem(key, value) method must first check if a key/value pair
with the given /key/ already exists in the list associated with the
object. If it does, and the /key/ refers to a read-only property name,
the method MUST throw a NoModificationAllowedError. Otherwise, it
shall follow the algorithm described in WebStorage.

The removeItem(key) method must first check if a key/value pair with
the given /key/ already exists in the list associated with the object.
If it does, and the /key/ refers to a read-only property name, the
method MUST throw a NoModificationAllowedError. Otherwise, it shall
follow the algorithm described in WebStorage.



Mitch, Mark: Does the above normative text address your concerns about
permitting read-only attributes with respect to pre-provisioned keys?
Vijay: It seems the above text should adequately cover the
origin-specified & origin-authorized distinctions. Do you agree?
Arun: While deriving from "Storage" is nice, I get the impression
WebStorage is the black sheep of web APIs at the moment - in part, due
to its synchronous nature. It seems overkill, but an alternative would
be to expose an entire IndexedDB IDBEnvironment on every Key. Am I
crazy for thinking that?

Received on Tuesday, 28 August 2012 01:50:59 UTC