It really depends on what you mean by really good. I agree that you can't be really good at many things - but only relative to yourself. Meaning that if I (personally) practice Skill A for a week versus practicing Skills A,B and C in the same week I would almost certainly be better at Skill A.

But if you work on Skills A,B and C for a week and another dude works on Skill A for a week there's no guarantee that you're going to be worse than him. Depends on smarts, I guess.

I guess it's academic but inexplicably interesting to me.

Yeah. Except Google's DLF allows you to export just about anything and everything you can create in Google products. It's true that Google's search is it's bread and butter but in the battle for good will, Facebook keeps shooting itself in the foot.

I couldn't agree more with this one. I have trouble talking to people about this because I failed their interview so I come across as bitter (which I am). But this problem is not just Google's problem. It's systemic. Someone a long time ago decided to turn interviewing into a formula - a bad one - and it stuck. Drives me crazy.

Encouraging to see more development in this space. Thanks. I'm curious, though. How do you think this compares with the mongoose (http://code.google.com/p/mongoose/) project. Other than the fact that it's C++-based what would you say are the relative advantages/disadvantages?

Hmm, looks nice :-)

At a glance, I'd say it looks both more lightweight and more high-level than Lacewing (Lacewing won't host anything at all unless you add in a handler which calls SendFile or whatever, whereas Mongoose seems to have a concept of a document root and things like that).

Mongoose seems to use select() and nothing else (I only had a quick read through the source, mind), whereas Lacewing opts for things like epoll/kqueue/IOCP, which should mean that Lacewing might scale better to many clients.

Mongoose also appears to use multithreading, which Lacewing currently avoids in favour of the reactor-esque Lacewing::EventPump. Lacewing has, however, been designed with multithreading in mind, and it's something I'll be adding as an option for the Server and Webserver classes in the near future.

By the way - Lacewing does provide a C API too, despite being written in C++.

Mongoose is only selecting for the listening socket, so the comparison there isn't particularly valid. Mongoose scales as well as threads on its platform scale.

Mongoose also does a fair bit more than your software does, including SSL, CGI, HTTP Authorization, and file uploads.

Neither of them, frankly, are particularly trustworthy in their present state (Mongoose has apparently actually been audited by someone, but it too stores lengths in signed u64s). But Mongoose, for all its extra functionality, is actually somewhat smaller than yours.

I'm glad you're playing with this and wish you the best of luck, and would only urge caution about advocating that people adopt this code (or Mongoose). Most developers would almost always be better off with a better tested server, or one implemented entirely in a high-level language.

Hey, mine does SSL and file uploads. ;-)

The advice about developers being better off with a better tested server is very true, though, of course. I hope Lacewing might fit into that category one day, too.

Sorry for my ignorance, but could somebody point me to a more mature well-tested C++ webserver, as mentioned?

I honestly believe that you should avoid multithread support and instead focus on the current single threaded reactor pattern. Any developer found easily just attach something like a zmq ipc queue in order to support multithreaded handling, given that the request object is thread safe. This approach would just leave you with work which ensures that the protocol parser doesn't trump any I/O overhead.

This looks very cool, thank you for sharing.

As a father, I completely agree. As a c++ developer I'm counting down to the russian support calls.

I agree. Although this may not be the 100% certainty mentioned, it's another good data point. When boostrapping, it often feels like I'm working in an opinion vacuum (I don't count friends cause they tend to be annoyingly kind about these things). I like this idea.

Right. For me, it's not that they're instituting restrictive policies (which I can sort of understand in some cases). The problem is that it seems to be a moving target. If I was an iPhone developer I would feel like I was being toyed with.

Just wanted to add my thanks to the list. This was one of the bigger holes in document processing and now it's been filled for the most part.