Re: [hybi] Extensibility mechanisms?

[Ian Hickson <[e-mail]>]

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.


> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'