Re: [hybi] Process, was: Technical feedback. was: Process!

[Greg Wilkins <[e-mail]>]

Maciej Stachowiak wrote:

> Like I said, I think some of your points are really good. But the ones where you don't give a clear grounding in use cases or concrete problems to be solved read to me like
> you've assumed the solution.

When the good points are so soundly rejected and left un-addressed, it is hardly
motivation to carry on and provide more details on the other points.

I refer you to Justin's recent comment: "but this is such a ridiculously large pain
point for servers that is being constantly belittled by the person in charge of
the drafts that it makes me question even continuing to bother providing feedback
at all"

This is a sentiment I deeply share.

You say that server-side feedback is welcome, but I don't think there are many
server side people here feeling the luv'n!



> I just read that post, and I don't see any concrete use cases for arbitrary metadata. 
> You give some reasonable
> arguments for specifying a MIME type, but leap from there to
> arbitrary name/value fields. I did not see any connecting logic.

Well one of the key things about supporting arbitrary meta-data is that is
allows unanticipated future requirements to be met without having to rev the spec.

Now it may be that we can address all the issues raised (negotiating timeouts,
supporting different content types, orderly close initiated by either end or an
intermediary, handling large message etc), without supporting
arbitrary meta-data.   But in my experience, to come up with specific
solutions for these 3 problems would break the 0,1 or infinity rule -ie where
there are 3 use-cases, there are actually probably 4 or more.



> In some cases, you seem to be pushing some preferred design approaches without
> presenting a clear grounding in concrete use cases. 

See this just sounds like you are shooting the messenger.   So it's my fault the
spec does not address my concerns because i've been inadequate in the way that I've
framed my feedback and the editor of the document is faultless in his approach.

Great! you are really encouraging me to continue with this process.


Besides, this is such an unfair criticism both to me and the WHATWG editor.

Ian has taken an immense amount of time to engage in discussion here and to
try to understand our concerns etc.   I think he mostly does understand,
but simply does not agree.   It's not a communication problem.

Moreover, I've changed my preferred design approach to these problems so
many times that even I can't keen track of what I really would like to see.
Maybe I'd like to see multi-plexing in the base protocol, or maybe I'd just
like the base to be extensible enough that multi-plexing can be layered on
top of it.     There are lots of factors in making such a call, but first
we have to agree that multiplexing is a desirable feature either now or in
the future and what other features it would have to coexist with.

We are nowhere near that agreement, and without an agreed set of requirements
it is impossible to come to a consensus of a design approach.

This is why the charter of the WG does start at the requirements stage (much
to the scorn of the WHATWG editor).   So I think I might break off these
threads and follow the charter and participate in some threads about
requirements.


cheers