Re: [widgets] Seeking comments on Last Call WD of Widgets: APIs and Events spec; deadline 15 Sept 2009

On Fri, Aug 21, 2009 at 1:10 PM, Scott
Wilson<scott.bradley.wilson@gmail.com> wrote:
> Metadata Attributes and the Storage Area
> ================================
> I don't think its clear from the spec if metadata attributes are within the
> scope of widget.preferences and must be stored in the same storage area.

ok, I can try to clarify this. But I'm not sure where this is confusing.

> E.g. Does widget.preferences.getItem("name") == widget.name? if not, then
> why does a script calling widget.preferences.setItem("name", "blah")  need
> the UA to throw an exception?

Hmm. That is certainly not what was implied. They are totally separate
things. Can you point me to the offending text in the spec?

> Some options:
> 1. metadata attributes must be treated as equivalent to preferences, and in
> fact should be able to be accessed in the same manner;

No, this is not what we want.

> 2. metadata attributes are not the same as preferences, and their storage
> should not conflict with preferences. Therefore preferences with the same
> keys as metadata attribute names are fine.

Yes, this is what is what we have been intending to spec. Again, what
part of the spec is broken and implying otherwise?

> 3. metadata attributes should not be made accessible using
> widget.preferences, but must be treated as being stored in the same storage
> area, and potentially have conflicting keys; therefore preferences with the
> same keys as metadata attribute names are disallowed.

No, certainly not. They are separate things.

> (We currently implement using option 1, but would be happy with option 2. I
> don't think option 3 has much merit)

Agreed. I think we have consensus in the WG that 2 is what we want and
what should have been in the spec all along.

> Read-only Metadata Attributes
> ========================
> For read-only attributes, I note that there is no actual conformance
> statement. I suggest adding a nice broad one in 6.1, to allow more UAs to
> reach conformance:
> "A User Agent SHOULD take reasonable steps to prevent author scripts from
> modifying Metadata Attributes. Where it is not practical for a User Agent to
> prevent an author script setting or clearing a Metadata Attribute during
> runtime, the User Agent MUST NOT persist any such modifications for further
> instantiations of the Widget."

>From my understanding is that private members can be used in Javascript:

http://www.crockford.com/javascript/private.html

Hence, it would be possible for a javascript implementation of the
spec to comply.

Having said that, as the spec says, the interfaces are defined in
terms of IDL which already defines readonly:

"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. "

To include the text you suggested would be a tautology (and possibly
lead to further confusion, as it redefines readonly). For a
script-based implementation, I would follow this document:

http://ejohn.org/blog/javascript-getters-and-setters/

The fact that JS still allows you to delete properties is not the
fault of the implementation (it's a consequence of the platform on
which the implementation is done). The implementation should still be
able to conform (read "pass the test suite") even though such a thing
can happen.

> So a web browser implementing the spec can declare the attributes in the
> Window and make them read-only as it controls the environment, and Wookie
> can just not save any changes beyond the scope of the current browser
> session.

Right.

> 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
> a NO_MODIFICATION_ALLOWED_ERRexception. The NO_MODIFICATION_ALLOWED_ERR is
> defined in the [DOM3Core] specification."
> OK, this is fine, we can implement this. However, what about:
> widget.preferences.blah = "new value"; // where "blah" is a read-only key
> We really don't have any way to prevent this happening or throwing an
> exception. Luckily for us the conformance statement above doesn't mention
> it, which means we don't have to!

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.
> 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
> operations using alternative syntaxes; however unless the conformance
> 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
> spec :-(

Nah! we will work it out :)

-- 
Marcos Caceres
http://datadriven.com.au

Received on Friday, 4 September 2009 14:47:43 UTC