Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 44708 invoked by uid 500); 27 Aug 2002 15:45:42 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 44639 invoked from network); 27 Aug 2002 15:45:41 -0000 Date: Tue, 27 Aug 2002 11:45:43 -0400 (EDT) From: Ryan Bloom To: TC Cc: dev@apr.apache.org Subject: Re: APR benefits beyond portability for www.asterisk.org In-Reply-To: <05c301c24d54$8d35cc60$0101a8c0@dev.topcat.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 > GTK > ACS > 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 _______________________________________________________________________________ Ryan Bloom rbb@apache.org 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------