Re: Constraints 2014 new slides

Jan-Ivar,
   I do like the way that you included the list of requirements in your 
slide deck, and have made a real attempt to meet them.  The reason that 
the requirements look like they're skewed to the current spec is that 
they grew up along with it.  We didn't start with a clear set of 
requirements, but with a general idea.  As we discussed things, we got 
clearer on what we wanted, and so what I'm calling "requirements" are 
the main points we agreed on as we went along.

I would also like to clarify my earlier point on the simplicity of 
syntax.  It's very much a matter of personal taste.  I was raised on 
LISP and find nested structures quite intuitive, while I dislike 
syntaxes that have semantically distinct concepts at the same level - so 
"width" and "require" are at the same level in the dictionary yet mean 
very different things.  I don't expect others to share my tastes, but I 
don't  think that there is a fact of the matter as to which of the 
proposals is simpler.

- Jim

On 3/27/2014 2:54 PM, Jan-Ivar Bruaroey wrote:
> On 3/27/14 2:30 PM, Jim Barnett wrote:
>> This all will be aired on the call, but let me agree with ekr for the 
>> record.  I don't see how this new proposal is an improvement on the 
>> existing one.  It is less powerful (can't couple constraints, only 
>> limited back-off),
>
> I included a slide with your requirements in the new slide deck, so 
> hopefully we can discuss them if there is time.
>
> I think that is generous given how the language of those requirements 
> skews to the current spec (steeped in its language at least), and it 
> is obviously written in hindsight. It doesn't look like the kind of 
> requirements I would expect to see ahead of a project.
>
> For instance, what you call "back-off", I might turn around and call 
> "preference", like "I prefer higher frameRates over lower ones". True, 
> the syntax is more limited in that you can't say "if I can't have a 
> boat then I want cake",  but people may view that as a win. I think 
> some would say we went overkill here a long time ago.
>
>> and to my eye the syntax more confusing.  We have an existing 
>> proposal that has been through a lot of discussion and we should not 
>> change it without very good reason, particularly if we want to get 
>> done this decade.
>
> I think the faster path is to avoid inventing odd non-WebIDL APIs. The 
> sooner we stop innovating in this space, and use boring WebIDL, the 
> sooner we can get back to our core mission.
>
> .: Jan-Ivar :.
>

-- 
Jim Barnett
Genesys