Re: [hybi] Extensibility mechanisms?

[Mike Belshe <[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
>