choice of embedded httpd lib

Angus Salkeld asalkeld at redhat.com
Tue Aug 16 22:12:39 UTC 2011


On Tue, Aug 16, 2011 at 10:47:08AM -0400, Jeff Darcy wrote:
> On Thu, 11 Aug 2011 14:16:08 -0600
> Pete Zaitcev <zaitcev at redhat.com> wrote:
> 
> > On Thu, 11 Aug 2011 09:39:16 +1000
> > Angus Salkeld <asalkeld at redhat.com> wrote:
> > 
> > > So, are you happy with it? Do you think it can provide the required
> > > security features needed in aeolus?
> > 
> > My personal experience is limited, but it looks that the microhttpd
> > library does everything we need. In particular it is compatible with
> > pthreads. We do the authentication outselves, because the library only
> > provides the "Basic" authentication, whereas we need a different kind,
> > known as "Negotiate". The library permits this sort of thing, by
> > letting the users set necessary HTTP headers. We do not support SSL
> > at present.
> > 
> > > Are there any other libraries that are worth looking at that you
> > > know about?
> > 
> > Sorry, I'm ignorant about it. Jeff Darcy made the decision originally,
> > perhaps he remembers what else he considered (on cc:).
> 
> At the time the project started, the available choices seemed pretty
> limited.  I would actually have preferred to work in one of the
> higher-level languages, especially Python which I know well, but the
> nature of the project dictated a few requirements that most frameworks
> (surprisingly!) didn't seem to meet:
> 
> * I have considered STEM (Single Threaded Event Model) frameworks to be
>   beneath contempt for years, due to their inability to use more than
>   one core effectively in a many-core world.  About half of the
>   frameworks I looked at got eliminated right off the bat because of
>   this.

Well I surpose this depends on your performance needs, we don't
really have such high performance needs.

> 
> * The ability to stream multiple objects simultaneously was an absolute
>   requirement, and many of the remaining frameworks had weak or no
>   support for such streaming (often due to WSGI limitations in the
>   Python world).
> 
> * Fine-grain control over headers and status codes was another
>   requirement, and some frameworks took this control away from the app
>   developer.
> 
> * Being in a language I already knew wasn't a requirement itself, but
>   did somewhat constrain my ability to evaluate frameworks against
>   other requirements.  When I was unsure, I erred on the side of
>   caution, which might have led me to reject options which actually
>   would have sufficed.
> 
> In the end, microhttpd was the first framework I found that met
> requirements.  I looked around a little bit more in hopes of finding
> something with greater ease of use, but the time came when I just had
> to get on with writing the code so that's the path I chose.  It seems
> to me that it has held up pretty well, but I'll defer to Pete or Jim on
> that because they've actually had their head in it more this past year
> or so.  I've successfully used bottle.py for another project (the
> management framework for HekaFS) and might well consider something more
> along those lines if I were to attempt something similar to iwhd today.
> 

Thanks for your explaination, that helps a lot. I think we will
also use microhttpd. The API looks flexible and quite easy to use.

Regards
Angus Salkeld



More information about the iwhd-devel mailing list