[widgets] Comments on section 5.1 protected preferences

[Scott Wilson]

I've investigated this issue, and I'm afraid it does not seem possible to have protected attributes in a pure JavaScript implementation. While private attributes and protected methods are supported using closures, protected attributes are not; a private attribute exposed using a public or protected method would protect the attribute, but would not provide the functional behaviour required by the spec (i.e. a widget.preferences.foo would return "function" and not the value of the private attribute "_foo"). I'm open to alternative suggestions, but I've had a good go at this and haven't found anything that would work as specified.

"The attribute is read only if the "readonly" terminal is used in the
definition. An object that implements the interface on which a read
only attribute is defined will not allow assignment to that attribute.
It is language binding specific whether assignment is simply
disallowed by the language, ignored or an exception is thrown. "





S

I suggest as a way forward that, as the "read only" definition provided by IDL for metadata attributes does support a pure JavaScript implementation, that 5.1 also adopts the same approach: E.g., if a Widget package defines a read-only preference "foo", and the runtime Widget instance calls "foo = bar", a JavaScript implementation is still conforming if it does not persist the change for subsequent sessions (the "ignore" clause). This would probably be quite simple in terms of text, as all that would be required would be to state that protected keys should be treated as read-only attributes.

Section 5.1 and "syntactic sugar"
==========================
Section 5.1, para 4 reads:
"Upon invocation of the setItem() or removeItem() method by an author
script on a protected key, user agent must throw

defined in the [DOM3Core] specification."
OK, this is fine, we can implement this. However, what about:

We really don't have any way to prevent this happening or throwing an

it, which means we don't have to!

a NO_MODIFICATION_ALLOWED_ERRexception. The NO_MODIFICATION_ALLOWED_ERR is widget.preferences.blah = "new value"; // where "blah" is a read- only key exception. Luckily for us the conformance statement above doesn't mention

Hmm...

However I don't think this was the intention - it just shows one of the problems with the "syntactic sugar" interpretation of WebStorage. For any UA other than a browser, you really don't get the option to protect exposed

javascript properties.

Are you absolutely sure about this? No fancy closures, or using
Crockfords' methods will help here?

I suggest changing the example in 6.4.2 to use getItem(), and adding a note

re: alternative syntax.

operations using alternative syntaxes; however unless the conformance

spec :-(

Personally I'd rather exclude them for the sake of interoperability. If not, 5.1 para 4 & 6.4 para 4 need changing to cover semantically- equivalent requirement is reworded as per my suggestion above for read-only metadata attributes, we probably have to give up any hope of ever conforming to the

Nah! we will work it out :)

smime.p7s
Description: S/MIME cryptographic signature