[Bug 26372] Report issues/events not related to a specific method call

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372

--- Comment #28 from David Dorwin <ddorwin@google.com> ---
(In reply to Boris Zbarsky from comment #27)
> > In this case, this seems equivalent to a simple event with an attribute or
> > method to query, right?
> 
> Yes, except it acts like "normal" JS objects from the API consumer's point
> of view.
> 
> > but is such a solution really better than having a simple event (or promise, as
> > is the case for |closed|) for each one?
> 
> That's an API design decision in the end.
> 
> I would say that for state that is synchronously available and easily
> computed using Object.observe is probably the right way forward in terms of
> creating developer-friendly APIs.
> 
> For state that is not synchronously available, promises seem like the right
> approach.

Thanks. My takeaway is that Object.observe() might be a good replacement for
events that indicate a specific attribute has changed but probably does *not*
fit the keys list use case well (if only due to the array mutability issues).

We could use it to add/replace simple events or our attributes (i.e.
expiration), but it may still be better to stick with events for such a complex
object and because it is more common for DOM objects.

> > What if MediaKeySession had a method named getKeys() that
> > returned (a reference to) an array of key IDs that could then be observed.
> 
> API like this is possible to create, but there are some gotchas that you
> need to be careful with.  For example, what would happen if the script
> mutated this array?  Would this affect other callers of getKeys(), or would
> each getKeys() call return a new array?  Both answers have some problems,
> fwiw: in the former case, if the return value of getKeys() can change you
> have to define exactly how the array is updated, while in the latter case if
> the value changes you have to update all the different arrays you ever
> returned.

Good points. Unless/until bug 23682 comment 0 item B is resolved, we should
probably avoid this for the keys list.

> > Is there something like a map already defined that we could use?
> 
> ES has a Map object, but I don't believe changes to the map are observable
> sanely via Object.observe.
> 
> > Object.observe() allows applications to be informed of the exact change and
> > take action, but it probably adds some TBD amount of complexity to the spec.
> 
> I don't think it adds any more complexity than firing a DOM event, at least
> once someone writes a generic "send an observer notification" hook in the
> DOM spec.

The complexity I was referring to is the potential for new types (see below),
observing a change and checking the new value (doesn't work - see below),
gotchas like you described above, etc.


Can an observable object define the structure of its records? As an example,
the array model doesn't work because we need names/values not positions and old
values. (Without such information, you still need to get the entire array
because the position and value could have changed again before you could query
based on a record.)

If so, we might be able to solve some of these problems by defining a custom
observable MediaKeyStatusMap interface whose records include the keyId (rather
than index) and for type 'update' would include the new status value in
addition to the old value.

(FYI, my main reference is the the examples at
http://wiki.ecmascript.org/doku.php?id=harmony:observe_api_usage.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 24 September 2014 01:15:06 UTC