Re: Defining ConstraintSet and the constrainable algorithm in terms of it

On 2/6/14 5:49 PM, Harald Alvestrand wrote:
> As promised, hashing out the language of ConstraintSet....
>
> First, an admission: I don't understand how initialization of complex 
> argument types in WebIDL is supposed to work.
>
> I tried to parse the WebIDL spec to figure out "here is how you 
> specify that an argument of type T can be constructed from a JS Object 
> O when O is passed as an argument to the function that takes an 
> argument of type T", but I did not find it. So I guess I'm left with 
> prose - and possibly supporting WebIDL.

If by "type" you mean Interface, then no. Interfaces are 
browser-objects, not content JS objects. Defining that surface between 
browser and content is the whole point of WebIDL.

Content JS objects may be passed in as dictionary, object or any, in 
decreasing order of preference. That's because interacting with JS 
objects is dangerous for a browser as there are zero guarantees in 
behavior even for the simplest interaction. JS objects can contain 
anything. Dictionaries have a well-defined processing order because of 
this (the precise way and order in which the information is extracted 
from the foreign object). The passed-in object for a dictionary argument 
is effectively cloned, such that the deterministic clone and not the 
foreign object is examined by the browser, for safety. That's how scared 
DOM people are of direct interaction with JS objects. Our binding code 
takes care of this. If an API argument is of type "object" or "any" then 
all that binding code is skipped, and we have to write manual validation 
code and endure extra security reviews where DOM people yell at us.

If we're not going to use a dictionary, we should define the processing 
model for the object argument in the spec. The way I chose to implement 
it, I copy the JS object almost immediately to a dictionary (after 
scanning for unknown mandatory keys, which if found, will fail the call 
always). That way the processing model is well defined. I suggest 
recommending that implementation strategy in the spec, as I can't think 
of a simpler way to explain the resulting processing model.

> The algorithm I have in mind, which is a making-more-precise of 
> section 11.1.2 of the current (abbreviated) draft, says:
>
> WebIDL:
>
> typedef object ConstraintSet;
>
> The following operation is executed to figure out if the Constrainable 
> object O, which has capabilities CA, satisfies ConstraintSet C:
>
>    - For each immediate attribute A of C (as defined by HasOwnProperty):
>      - If N, the name of A, is not a member of CA, fail.
>      - If V, the value of A, cannot be interpreted as a 
> ConstraintValues, fail.
>      - If V does not permit any of the allowed values for CA(N), fail.
>      - Set the constraint of N in O to be the intersection of any 
> previous constraint
>        and V. If the result of this intersection is empty, fail.
>    - If satisfaction succeeded, return the newly-constrained object O.

As mentioned above, I would simplify this by using the rhetorical device 
of an early conversion step to a dictionary, and let the remaining steps 
operate on a dictionary. That seems safer, and avoids dealing with crud 
like HasOwnProperty.
> Here's where the now-deleted definition of ConstraintSet may come in 
> useful:
>
> In this algorithm specification, the access to C is done as if C had 
> the WebIDL definition:
>
> [NoInterfaceObject]
> interface ConstraintSetInternalRepresentation {
>     ConstraintValues getter (DOMString name);
> };

This strikes me as an odd comparison since an interface is a 
browser-object, not a content JS object. Instead, I use a dictionary for 
the internal representation: 
http://mxr.mozilla.org/mozilla-central/source/dom/webidl/MediaStreamTrack.webidl#23

.: Jan-Ivar :.