[OSM-dev] C++ implementation of the API

Tom Hughes tom at compton.nu
Thu May 22 00:06:18 BST 2008

In message <1211406345.4742.39.camel at test.asus>
          Joachim Zobel <jzobel at heute-morgen.de> wrote:

> Am Mittwoch, den 21.05.2008, 11:14 +0100 schrieb Alex Wilson:
> > Further to earlier discussion on this list, I've been looking into
> > writing a C++ version of the OSM API server. When discussing this
> > before, it was suggested that an Apache module would be the best way
> > to plug such an API into the OSM server. Just out of interest: what
> > are the advantages of a standalone Apache module versus a plugin
> > module to Ruby that uses the existing codebase to parse the urls etc
> > but calls out to the C++ api to do the heavy lifting?
> As far as I can see mod_ruby does not give you access to the apache API.
> Writing a native Apache module does. Once you know what this means you
> know its a big difference.

This has nothing to do with mod_ruby though - he was talking about
hooking into our existing ruby code, which is running as rails under
fastcgi and has nothing to do with mod_ruby.

We're not even using Apache - we're using lighttpd to front things
and pass requests on to rails via fastcgi when required.

> I am however not shure if this is useful for writing an OSM API server.
> The reasons for writing an apache module is that its truly multi
> platform (TM), that it has a small memory footprint, that it can do HTTP
> and network stuff that can not be done otherwise and that it can do in-
> and output filtering.

I'm not particularly bothered if it is a module or not, though it
seems like the most efficient way for compiled code to get access
to a request - what are the alternatives? a compiled CGI program? a
fastcgi server?

> Writing Apache modules in C is hard, and I don't think using mod_cpp
> will make it much easier. Doing Apache modules in Perl (mod_perl has API
> access including filters) is a lot easier. For modules using the C API
> read Nick Kews book (ISBN 9780132409674).

Ye gads no. We want to keep the memory footprint under some sort of
control so mod_perl is a non-starter.


Tom Hughes (tom at compton.nu)

More information about the dev mailing list