2011/6/15 Colm MacCárthaigh <c...@allcosts.net>: > On Wed, Jun 15, 2011 at 3:01 PM, Paul Querna <p...@querna.org> wrote: >> I think we have all joked on and off about 3.0 for... well about 8 years now. > > At least! > >> I think there are exciting things happening in C however. > > I love C, but unless we can come up with something radical, it's hard > to see a way out of the prison it creates. That realisation led me to > hacking mostly on functional-oriented servers. I'll try to explain why > - in case any of those thoughts are useful here too :) > > I like the things you've pointed out, but they seem relatively > cosmetic. Things like the parser, async, event and portability > frameworks are really cool - but hardly fundamental. Anyone could use > those, in any language - it's not a real leap in the field. Similarly, > SPDY, websockets, COMET and so on are ultra-cool - but are still > potential bolt-ons to almost any kind of webserver. It sucks that we > don't do them well, but doing them better won't fundamentally change > the market or the pressures on adoption. > > Today webservers are almost entirely network I/O bound - disk seek and > CPU speeds are pretty great these days, way faster than is really > neccessary. In a properly architected set-up, end-user delay is really > about the limitations of TCP. You can multiplex and use keepalives as > much as you want, you'll eventually realise that the size of the world > and speed of light mean that this inevitably ends up being slow > without a lot of distributed endpoints. > > But we have some cool secret sauce to help fix that. I think the best > architectural thing about Apache is buckets and brigades. Using a list > structure to represent portions of differently-generated content like > that is great. Imagine how much better wordpress would run if PHP > represented the php scripts as a some dynamic buckets intermingled > with some static file io buckets (and even repeated when in loops). > There'd be a lot less data to copy around. > > Now imagine a backend that could identify the dynamic buckets and, by > forbidding side effects, parallellise work on them - a bucket as a > message in message-passing system of co-routines, for example. Imagine > that in turn feeding into a set of co-routine filters. That's > fundamentally different - it parallelises content generation, but it's > really really hard to do in C. > > Then next, imagine a backend that could identify the static buckets > and re-order them so that they come first - it could understand things > like XML and Javascript and intelligently front-load your transfer so > that the content we have ready goes first, while the dynamic stuff is > being built. It's a real layer-8-aware scheduler and content > re-compiler. Again it's really really hard to do in C - but imagine > the benefits of a server layer that really understood how to model and > re-order content. > > These are the kinds of transform that make a webservers job as optimal > as it can be. Network data is the most expensive part of any modern > web application, in terms of both time and money, so the ecosystem > faces huge economic pressure to make these as optimal as possible over > time. Things like SPDY are just the first generation. > > It'd be cool if Apache 3.0 could do those things - we have some great > building blocks and experience - but it feels like a language with > support for first-order functions and co-routines would be better at > it. > > Again, I'm just thinking out loud :)
I think its an interesting idea, focusing on a content aware server architecture; An example of this is SPDY's ability to push content for a client -- For example, a client requests /index.html, you can push /css/main.css to them without waiting for them to request it. I think as far as the implementation language, you seem to be asking for Go? Which I really really like, but it seems hard to make extensions/module APIs. Of course, the other option is to just write it in Node.js.... I mean most of the web erver is not about the lower bits, its about configuration and content generation.
