Re: [hybi] Extensibility mechanisms?

[Mike Belshe <[e-mail]>]

On Wed, Jul 21, 2010 at 3:17 PM, Ian Hickson <[e-mail]> wrote:

> On Tue, 20 Jul 2010, John Tamplin wrote:
> > On Tue, Jul 20, 2010 at 6:14 PM, Ian Hickson <[e-mail]> wrote:
> > >
> > > 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.)
> >
> > I still don't see the argument for servers written by amateurs.  I have
> > used far more quick-and-dirty web clients (telnet, socket/connect/write
> > in C, wget/curl, etc) than I have quick-and-dirty servers.
>
> That's largely because most protocols are such that you can't make a
> compliant server quickly. The one exception (which isn't a network
> protocol but is relatively similar for the purposes of this discussion) is
> CGI. That's a simple protocol, and there are many implementations of the
> server side of the protocol (that is, CGI scripts; the HTTP server is the
> client of the CGI protocol). Now, most people use libraries, of course,
> and that's fine. But the protocol is simple enough that you don't _have_
> to use a library, and some people don't.
>
>
> > If some amateur needs to write a server anyway, they aren't going to
> > write it from scratch even if it were possible for them to do so -- they
> > will find some library.
>
> Yes, for most existing protocols that is the sad reality. I think that's a
> failure on our part (the part of protocol designers). We can enable much
> greater experimentation, innovation, learning, and so forth, if we make
> lower the bar to the level of CGI scripts rather than keeping it at the
> level of HTTP servers.
>


>
> > Contrast this with embedded clients, which might well have tighter
> > constraints than most clients, and could benefit from having optional
> > features they could leave out that would be useful for more powerful
> > clients.  Meanwhile, the servers are going to almost certainly be on
> > more powerful machines, though granted they have more connections to
> > support.
>
> In the case of Web Sockets, most clients (by usage) are going to be Web
> browsers, so if we are forced to put complexity into the protocol, we
> should move it to the browser side. But in general we should keep that
> side simple too, so that custom clients can also be written.
>


>
> On Wed, 21 Jul 2010, Jamie Lokier wrote:
> >
> > All that's needed, for amateur programmer compatibility, is for the
> > "complex" performance-enhancing features to be optional negotiated
> > features on top of an extremely simple base protocol.  And for the
> > negotiation to be really simple too.
>
> Once the protocol is proven, I think it would make sense to add optional
> features. The protocol is designed to make that easy for us.
>
>
> On Tue, 20 Jul 2010, Roberto Peon wrote:
> >
> > We need browser-owned connections with a security model that allows
> multiple
> > tabs to share the connection safely.
> > This is probably the most important requirement for scalability as far as
> > I'm concerned. This requires fewer keep-alives (both because of fewer TCP
> > connections and because the TCP connection is more likely to have real
> > content sent on it instead of near-zero value'd keep-alives), it requires
> > fewer file descriptors, it requires fewer handshakes.
>
> This is pretty easily implemented at the application layer using shared
> workers.
>
>
> On Tue, 20 Jul 2010, Mike Belshe wrote:
> >
> > For as adamantly as Ian states that it should be a requirement, I am
> > just as adamant that it should not.
>
> It's quite possible that this working group should be working on two (or
> more) protocols, rather than trying to solve all our problems with Web
> Sockets. Or it could be that Web Sockets isn't the right solution for the
> problems that most people in this working group are trying to solve.
>
> Web Sockets is a trivially-implementable TCP-for-browsers protocol for
> long-lived connections. If that doesn't sound like the protocol you need,
> then you need a different protocol. If that isn't the protocol this
> working group wants, then this working group wants another protocol. I
> don't think there's anything wrong with that, but then we should work on
> that protocol, not Web Sockets.
>
>
> > 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.
>


> I disagree that the protocol's development has been in any way held up by
> this. I agree that we've talked about it a lot in the working group, but
> the spec itself hasn't been affected by this as far as I can tell.
>

To be specific, our earlier discussions about error handling, large frames,
and binary frames were all cut short under the "too hard for amateur
programmers".

Based on the +1s in this thread, I think many agree that this has occurred.
 I don't yet know if we mostly agree that amateur programmers is not an
overriding criteria, so how do we decide?  Can we get a group decision on
that now?

Once we have a decision on that, we can finish looking at the other issues
on the table.  If we agree that "amateur programmer support" is not a
feature, then it cannot be held up as an argument for or against any
proposed solution once we've decided upon it.  Or, if it is a priority, then
we should weigh all proposed changes against it to ensure that the
requirement is met.

Can we call a vote on this issue alone and settle it?  Chair-people, can you
offer guidance?  Without a decision on the importance of this issue, I know
we'll go circular again when deciding on other issues.




>
> > Every protocol expert I've spoken with agrees that amateur protocol
> > implementors should not be a requirement.
>
> And what did the protocol amateurs you spoke to say? It seems unsurprising
> that people whose careers are based on being able to solve complicated
> protocol problems should want protocols to be complicated.
>

I have yet to meet anyone that wants the protocol to be complicated, so
please don't say that I asked for that.  What I asked for is that the
protocol not be constrained by the need to be implemented by "amateur
programmers".

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
>