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