apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@ntrnet.net>
Subject Re: APR benefits beyond portability for www.asterisk.org
Date Tue, 27 Aug 2002 15:45:43 GMT
On Mon, 26 Aug 2002, TC wrote:

> Hi
> Over on the asterisk mailing list (asterisk@marko.net) there is a little
> discussion on what would be the best match for a portability layer
> for the core phone functions in asterisk...
> custom brew
> cygwin
> Netscape etc etc
> Beyond the portability are there other benefits you have noticed
> using APR in the last few years on the Apache Web server 

I would be happy to answer this.  But first, let me comment on a few of
the options above, and some of what we have learned.  I want to be clear
that I am not bad-mouthing ANY of those projects, they are all good, but
we have some knowledge in this area, so I am trying to help.

1)  Custom brew:  Please don't.  There are hundreds of custom portability
projects in the world today (most of them proprietary), the portability
problem will only really be solved when we all work together on it.  APR
(and the other projects above) have learned a lot from creating portable
libraries, use an existing library, and just make it better.

2)  cygwin:  I like the idea of cygwin, but in practice, I have found that
it doesn't work.  The problem is that cygwin binaries are not native
Windows binaries, so you will never get the performance you want when
using cygwin.

As for other advantages to APR.

> -maintenace
> -learning curve

maintenance and learning curve generally go together in my mind.  If the
learning curve is too high, the maintenance is impossible.  If the
learning curve is low, the maintenance is generally easy.  APR excels in
both areas.  People new to APR generally pick it up quickly, because the
functions are easy to understand, and they mirror POSIX as closely as
possible.  The hardest thing to grasp is the memory pooloing.

> -how about performance??

Apache has not suffered from performance problems related to APR, although
any portable run-time does incur some performance penalty.  We have a
couple of people who work very hard to ensure that our performance is the
best that it can be.

> -stability ??

APR is stable.  Code written on top of APR is stable, assuming the program
is written correctly.  As for the library itself, we do still make small
tweaks to the API occaisionally, but we are finishing all of those up
now.  You are asking about APR at the best possible time, because we are
about to release 1.0, and we have stated that the API will not change
during major releases.

Hope all of this helps you make your decision.


Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610

View raw message