[OSM-dev] Thanks

Alex Wilson alex_wilson at pobox.com
Mon May 12 22:29:33 BST 2008

I wouldn't plan to touch the back-end DB (is it MySQL atm?) - just write a
for-comparison C++ API - and if it's not faster, or it's considerably more
obfuscated and harder to maintain, then it can be left to decompose quietly,
unused... ;-)

I think the task is something sufficiently straightforward that the C++ can
be made very user-friendly and pretty easy to maintain. I think we'll have a
look at developing the Apache module and you can all see what you think
if/when it's done...



On 12/05/2008, Frederik Ramm <frederik at remote.org> wrote:
> Hi,
> > > If you're really adventurous then re-implement the whole server API in
> > > C++ - it's not a big deal, you can leave the UI stuff in Rails, just
> get
> > > the stuff from
> >
> > Is this an *open* thing? I'm serious.
> >
> > I mean... if a random user would write something like the OSM API in a
> > random database, that could seriously be evaluated?!
> I'm pretty sure it would.
> Until now we have had many people tell us that everything could be
> faster if implemented in "X", but as far as I can tell we never had
> anyone say "look I implemented everything in X and it is 10 times
> faster".
> Of course we always have to take into account how manageable something
> is for the community. Rails is very manageable, but performs less than
> stellar. A C++ API based on a popular SQL database would, I assume,
> perform almost stellar but be a little less manageable (old-fashioned
> guy that I am I'd trade in Rails for C++ any time but I know some of
> the more modern-minded people are doubtful - maybe the holy grail is
> somewhere in between, Rails reportedly has very good support for
> linking in bits of C code).
> If someone where to re-write the API in an obscure language with a
> database system that's hardly used in the OS community, and achieve
> 10 times better performance than we have, then I don't know whether
> that would be adopted - after all we need developers for the API and
> it's no good to throw rocks in their path by selecting too obscure
> technology. But then again, there will come a time when we will need
> the 10 times better performance, so who knows ;-)
> Bye
> Frederik
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080512/f7010f81/attachment.html>

More information about the dev mailing list