Re: Constraints structure and Capabilities API

You could apply a straight entropy-reduction technique:
1. Group everything that has a label section together.  "video" and
"audio" are obvious sections.
2. Create a set of constraint/capability objects such as "boolean",
and "min-max" to cover off the low end.

I think those two alone get you a long way.  Though you might be able
to create groupings under video and audio that make sense, but there's
a point where this goes too far.  How far you go probably depends on
how many capabilities you intend to have.

You don't want a complex hierarchy (c.f. OIDs) such that setting or
getting an attribute requires a massive search path like:
capabilities['section1']['audio']['foo']['opus']['bitrate']['envelope']['max'],
with checks for undefined all the way down...

--Martin

On 24 February 2012 06:01, Dan Burnett <dburnett@voxeo.com> wrote:
> I agree 100% and am open to suggestions on how to make it more hierarchical.
>
>
> -- dan
>
> On Feb 23, 2012, at 6:59 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> On 23 February 2012 12:29, Dan Burnett <dburnett@voxeo.com> wrote:
>>> Cullen, Neil, Tim Panton, and I have come up with the following proposal for Constraints and for Capabilities.  The latter is for the trusted case.  We can work out a subset of information to provide in the case where the Javascript/web developer is not trusted.
>>
>> Looks like a reasonable idea.  But every time I see a flat namespace
>> like that it makes me cringe.
>>
>>

Received on Friday, 24 February 2012 16:31:35 UTC