Re: [hybi] Extensibility mechanisms?

[Ian Hickson <[e-mail]>]

On Mon, 19 Apr 2010, Julian Reschke wrote:
> On 19.04.2010 02:05, Ian Hickson wrote:
> > On Sun, 18 Apr 2010, Scott Ferguson wrote:
> > > 
> > > The client and server APIs must be suitable for amateur programmers, 
> > > and the wire protocol must support those simple APIs, but it's _not_ 
> > > important that the wire protocol be implementable by someone who 
> > > can't understand buffering, chunking or encoding. After all, 
> > > HTTP/1.1 requires those capabilities.
> > 
> > IMHO, HTTP is a disaster in terms of getting multiple server-side 
> > implementations. Over three quarters of the market is dominated by two 
> > vendors, and the third largest vendor on a per-server basis is a 
> > company
> 
> Sounds like the browser market, btw.

The browser market is even worse. It's incredibly difficult to enter the 
market. That's one of the reasons I've been working on making HTML5 as 
accurate a description of what a competitive browser needs to implement as 
possible -- to make it easier to enter that market. Unfortunately there's 
little more we can do -- we can make the specs more accurate, which makes 
it less expensive to create a Web browser, but we can't fundamentally make 
the browser market simpler, because of all the legacy content.

With Web Sockets, there's no legacy yet. We have a more or less fresh 
start. So we can ensure that what we do is simple enough that we don't 
create this problem.


> > that runs a proprietary implementation and derives significant benefit 
> > from being able to do so. There are some custom servers, e.g. in some 
> > set
> 
> Where's the problem with that?

Your quoting is ambiguous here, but assuming you are referring to the 
third implementation being a proprietary implementation, it's not a 
problem. What I meant was that since that company benefitted from 
developing their own dedicated custom server, rather than using one of the 
three off-the-shelf solutions with more than 5% of the market (by domain), 
it might be the case that other organisations would benefit from the same 
ability, but find themselves unable to actually write their own server 
since it is such a complicated task. If this conclusion is correct, then 
it would lead to a further conclusion that we should probably ensure doing 
the same with Web Sockets is easier, so that one does not have to become a 
large company before one can reap the benefit.


> > top boxes or other network devices too small to run one of the few 
> > common servers, and many of those are highly incomplete or buggy 
> > implementations.
> 
> There are also many servers running, for instances, one of the many 
> Servlet/J2EE implementations. These may not be significant compared to 
> the absolute number of servers out there, but how is that relevant???

I'm not sure what you're asking.


> > I would not consider HTTP a model solution here. On the contrary. Its 
> > complexity has led to a rather stagnant monoculture which is an 
> > attacker's dream. A single exploit can affect millions of servers. ...
> 
> Yes. What does that have to do with the protocol, btw?

A simple protocol is far more likely to end up with more implementations 
and thus a far more heterogeneous environment.

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