On Tue, 30 Jun 2009, Greg Wilkins wrote: > > I believe the path to a good user experience is to give them an > environment that abstracts away the details of the protocol. Websocket > does this on the client side, so I don't see why this should not be done > server side. I would definitely enourage people to write libraries and the like to support WebSocket, indeed. I don't think just because it should be possible to write your own WebSocket server that everyone should want to do so. (Just like with CGI, most people use libraries, but it's possible and easy to not do so if all you want to do is something simple.) > But I do agree with you that the protocol should not be difficult to > implement and that we do not want a monoculture. But it is overly > simplistic to say a protocol that needs more than a few dozen lines of > code is going to be rarely implemented or of poor quality. It is definitely a generalisation, yes. I think there's probably a correlation between the typical size of a fully compliant implementation and the implementation complexity of the spec, and there's probably a correlation between the complexity of the spec and the likelihood that implementations will contain bugs. However, it's certainly not the only metric to spec or implementation quality. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.