[hybi] Resolving Issue 11 - Amateur programmer requirement [was: Extensibility mechanisms?]

[Ian Fette (イアンフェッティ) <[e-mail]>]

http://trac.tools.ietf.org/wg/hybi/trac/ticket/11 has been opened, and I'm
glad to see this explicitly tracked. It seems like we have a divergence of
objectives. Hixie has stated he wants to "[write] a protocol that
amateur programmers can implement easily." Many others on this thread have
shared their own opinion, and then the thread turned again to other topics.

Maciej referenced http://tools.ietf.org/html/rfc2026 and
http://tools.ietf.org/html/rfc4677 as specifying how such disputes are to be
resolved.

4677 seems to indicate that voting isn't the way to go, but instead the
chairs should direct the group towards rough consensus. I'm not sure we will
ever make everyone happy, but given the number of +1's on the thread I am
hopeful we might have "rough consensus" and make a large number of people
happy on resolving this issue. Are the chairs comfortable in declaring rough
consensus on this issue?

If not, looking at 6.5 of 2026 it seems to indicate that the Area Director
acts as an arbiter when the group / chairs cannot bring the group to rough
consensus. How do we move forward on this?

I think it is important that this issue get resolved, as many other issues
are ultimately coming back to this one after some amount of discussion, and
so while we've taken the first step of noting it as an issue, now we need to
resolve it. Leaving it open for any period of time I don't think is going to
help.

Apologies for forking the thread, but having a discussion in the middle of a
centi-thread that encompasses multiple conversations seems fraught with
perils of things getting lost.

-Ian


---------- Forwarded message ----------
From: Mike Belshe <[e-mail]>
Date: Tue, Jul 20, 2010 at 4:10 PM
Subject: Re: [hybi] Extensibility mechanisms?
To: Ian Hickson <[e-mail]>
Cc: Hybi <[e-mail]>




On Tue, Jul 20, 2010 at 3:14 PM, Ian Hickson <[e-mail]> wrote:

>
> (By the way, I spoke to Joe and he suggested that I post an e-mail to each
> thread to which I was replying, rather than replying to all threads in one
> bulk e-mail or replying to all the e-mails I'm replying to individually. I
> hope this compromise works for everyone; I know there was some controversy
> when I replied in bulk a few months ago. I apologise in advance if this
> causes a spike in traffic to the list.)
>
> On Mon, 19 Apr 2010, Roberto Peon wrote:
> > On Mon, Apr 19, 2010 at 2:20 AM, Julian Reschke wrote:
> > > > On 19.04.2010 10:48, Ian Hickson wrote:
> > > > >
> > > > > There are many many implementations of HTTP. Some fast, some not
> > > > > so.  Some complete, some not so.
> > > >
> > > > I think we can get orders of magnitude more complete implementations
> > > > of Web Sockets than of HTTP if we keep the protocol trivial.
> > >
> > > Yes. That's a given. Make it less complex, and it will be easier to
> > > completely implement.
> >
> > This isn't true! Make it (the protocol) less complex and it will be easy
> > to implement something which *conforms to the spec*, but not necessarily
> > something which scales and is robust, reliable, and scalable in the face
> > of all the stuff that happens out there.
>
> Not all implementations have to scale to a million QPS or withstand DDOS
> attacks for weeks at a time. Most implementations of Web Sockets will
> likely be for small amateur projects that are lucky if they average 1 QPH,
> let alone 1 QPS.
>
>
> > The latter part is what really worries me. We really need to be sure
> > that the protocol that we create allows for an implementation of a
> > server to do these things.
>
> I agree that we shouldn't make the protocol impossible to scale. If there
> are specific features in the protocol that make it impossible to scale,
> please do raise these as issues. However, one doesn't have to make a
> protocol complex to make it scale.
>
>
> > If the (hopefully small) added complexity is too much for the amateur
> > programmer, then they should use the API level.
>
> What I'm interested in personally is writing a protocol that amateur
> programmers can implement easily. If we say they have to use someone
> else's code to do this, then that's a failure, IMHO. (Though as I've
> mentioned before, if people have different goals or priorities, I have no
> problem with separate protocols also being designed to address those --
> Web Sockets doesn't have to be everything for everybody.)
>

For as adamantly as Ian states that it should be a requirement, I am just as
adamant that it should not.

But more importantly, this single issue has been holding protocol progress
hostage.  Naturally, any feature has some amount of complexity.   But this
requirement creates an invisible, and subjective barrier to each feature.
 Is the feature too complex for an amateur programmer?  Nobody knows, and
everyone disagrees, because it is a subjective criteria.  So we spin and
can't agree.

Every protocol expert I've spoken with agrees that amateur protocol
implementors should not be a requirement.

Is there some way we can vote to either keep or nullify this requirement now
and never come back to it again?  I'm tired of this obstacle holding
everything up.

Mike




>
> --
>
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>


_______________________________________________
hybi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hybi