The Constrainable pattern is not general

Reusing parts of Constrainable is easy, since it is built on reusable 
stuff, like dictionaries.

But the bar must be that the entire pattern is reusable, with every ugly 
corner, or the pattern is too big.

So we must ask:

 1. How general is this pattern?
 2. Is it the best solution to the problems it carves out?


With no proof or use-cases offered, we must attack the origin of the 
pattern.

One origin use-case of Constraints, which are at the core of 
Constrainable, is camera selection: to let webpages triage a user's 
cameras by properties, without permission, for the purposes of never 
asking for them. Sounds silly, but this was a core problem which simpler 
solutions were or could be rejected over, hence it informed this design 
and allowed it to succeed.

This turned out to be a feat somewhere between a blindfolded magician 
knowing your camera (a trick, he knows), and a robot moving a vase 
without breaking it. In hindsight, given that this whole problem falls 
away once permissions are granted, I think we need to re-ask at what 
cost we needed to solve this, because the relative complexity/reward 
ratio is astounding to me, requiring us (the group) to foresee all sorts 
of rule needs and abandon WebIDL for inputs, just to ensure that a long 
tail of mostly advanced users whom we'll race to stay ahead of with 
testing, will be able to fail nicely in a way that fools this group into 
thinking no intrusion happened. But I digress. The question here is: 
will we need to do this again? I hope not.

The other origin use-case is to let multiple webpages modify a single 
camera at the same time - an oddly unchallenged idea - by letting the UA 
arbitrate control, using no contextual judgement but by following 
generic rules instead. There's no indication that these rules are 
general, or will work in other contexts, or will work in this context in 
the future without modification, or that the result in any domain will 
be pleasing.

No other use-cases have survived vetting.

This pattern seems neither general nor stable to me.

Every abstraction has a cost. I think the burden of proof is on others 
to show that this pattern is reusable, that the rules are general, and 
finished, and that it is the best solution to another problem.

If they can't, then the pattern doesn't get to stay around, it gets 
folded back into gUM for the obvious advantages of context that this 
brings back.

.: Jan-Ivar :.