Re: [boost] surveying async network io libraries

From: Jose (jmalv04_at_[hidden])
Date: 2005-08-11 11:16:54

On 8/11/05, Felipe Magno de Almeida <felipe.m.almeida_at_[hidden]> wrote:

> > I think there are three levels of demand for a boost networking library
> >
> > 1) reactor --> for users wanting to develop network apps
> 
> I would add proactor in this level also.

Proactor should go in the third level to keep this simple and maximize
adoption. The reactor pattern with an http example would get library
users coding right away
The asio library also implements the proactor pattern

> > 2) fastcgi --> for users wanting to develop web apps interfacing with
> > existing web servers
> 
> Is this possible into boost? cgis arent too much tied to the web
> server? This would lead to too much maintenance overhead to keep it
> working with the most of them.

It may sound odd to mention fastcgi here. 
Check this for background info http://cryp.to/publications/fastcgi/

The fastcgi interface is quite stable and the actual idea here is that
you can use any front end web server that supports the interface. The
architecture is quite elegant if you think that the front end support
all the common web stuff and you have a custom server that ties nicely
with the web server. Again it might sound rare to mention cgi here but
I think this would tie nicely with the idea of making boost a powerful
library for any type of network apps, web apps being the most common.

> > 3) other --> for users wanting to develop very complex network apps
> > where more abstractions are needed (combining reactor, threads, ...)
> 
> Or the proactor could go in here.

Yes. Logging would also be a core part here. The idea is not to
reinvent ACE but to have a progressive framework that you can start
with at level 1 but move to level 3 for any type of serious networking
app. There is a limit here where you probably end up using ACE for
really complex stuff.

> And as for fastcgi it could be an "another library" that uses one of
> the levels of the networking library.

 In an abstract way I compare fastcgi to regexp. They are de facto
standards for doing certain things and as result they are very useful.
Again, the fastcgi architecture is elegant but not widely used because
it is not in the vendor's best interest.