Re: Capabilities vs SupportedConstraints

Hey Harald,

I didn't mean to start a big discussion that would cause a lot of 
changes. Yet I have to stick to my original comment that from a 
developers point of view this is confusing and "at least" needs a little 
more discussion in the spec.

I also think that if nothing else, the naming and use of language is 
confusing - even in your language below.

> SupportedConstraints was added  to get around the question of "how do
 > I know that my requests won't just be ignored because of the
 > Dictionary rules?".
> The natural (to me, anyway) way  of generating supported constraints
 > is to have the UA dump the content of its constraint-parsing lookup
 > table, without any regard to whether there are any such devices or
 > not.

If we stuck with that then putting something along those lines in the 
spec would be a very useful start.


>  So I'd expect getSupportedConstraints() to return a lot of
 > strings like "reallyFutzyExperimentalConstraint" and
 > "propertyOfDeviceNobodyHas".

Well it returns a Dictionary of keys who's values are all true and the 
statement " Any constraint names not supported by the User Agent /MUST/ 
not be present in the returned dictionary." uses the now confusing word 
"supported". So you're saying that "supported" as in 
getSupportedConstraints() really means "has a key in the UA's 
"constraint-parsing lookup table". I'm not sure this matches with the 
common developer perception of the word "supported" - certainly without 
more explicit description in the spec.


 > getCapabilities, on the other hand, should return the constraints
 > that are actually useful for a specific context - they should
 > reasonably be generated by asking each device driver what constraints
 > it supports and what the values are

But this is why I say the word "supported" is now confusing. Here you 
say "by asking each device driver what constraints it supports...".

So we have "supported" by having a key in the UA's constraint-parsing 
lookup table and "supported" by the device driver.

It seems to me that the first supported would be the super-set and the 
second supported is a subset, and that it would be productive to give 
these two discrete sets some clearly defined and distinct names to make 
this clearly understandable.

I would also note that this seems 180 degrees opposed to Jan-Ivar's use 
of the terms Capabilities/Constraints/Settings (which I personally like).
e.g.

Capabilities are the entire set of potential modes or features the 
device is "Capable" of (not which Constraints the device drivers support).
Constraints are the structures that can be used to "Constrain" the 
potential modes or features in order to change the device's state (this 
is the same).
Supported Constraints are the sub-set of Constraints that both the 
device AND the UA are able to understand and attempt to apply (this is 
not just the constraint-parsing table but also what the device drivers 
support).
Settings are the final values a mode or feature has been "Set" to (this 
I'm hoping stays the same).


 > So to my mind, they're fundamentally, deeply different, and SHOULD
 > NOT be merged.

I think there's 2 questions here.

1. Should the language be made more explicit

My vote here is +1

2. Should we change the structure as part of this tidy up

I'm all for this change (and think the discussion above has raised some 
key points worth considering), but my primary goal is making sure that 
the language of the API and the spec is more understandable in this area.

roBman

Received on Tuesday, 4 November 2014 23:33:26 UTC