Re: Moving serf to commons?

On Mon, 4 Nov 2002, Aaron Bannert wrote:

> On Mon, Nov 04, 2002 at 12:42:24AM -0800, Justin Erenkrantz wrote:
> > Does anyone want to spearhead moving apr-serf to commons?
> > 
> > While I want to move it, I don't have the necessary karma/knowhow to 
> > do that, and I'd rather spend what little time I do have to spend on 
> > serf writing more code.  (Next on my list is deflate support.)
> > 
> > So, do we have any volunteers?  =)  -- justin
> 
> Woah woah woah...let's not be too hasty here. Just another week or so
> and we'll have the APR mission settled and have a solid target where
> this will go in Commons (or not). I'd be much happier to move things
> around after we know what we're moving out of and where we're moving to,
> since otherwise we're just strong arming this out of APR (which is an
> act I'm strongly opposed to). Patience. :).

I'm sorry, I don't understand this.  Why exactly are you so hell bent on
keeping this in APR?  The vote was taken in apr-serf, and the PMC was
asked if this should be moved.  The answer was yes.  Move it already.  If
apr-util moves out of APR too, then so be it, but apr-serf has already
made the decision to move.

When APR was created it was supposed to be about creating a project that
allows people to write portable C code.  At the beginning, we moved a lot
of code from httpd to APR that probably shouldn't have been moved.  That
was a mistake.  We tried to correct the mistake by creating APR-util
(which some of us fought against, because the project isn't about
portability).  That too was a mistake.  The code should have been moved
out of APR and put back in httpd-2.0.

Then, we created apr-iconv.  A project whose goal is to allow portable
codepage conversion.  That project should stay, because it is about
portability.

Finally, we created apr-serf.  A project that has nothing to do with
portability, except that it uses a portable run-time, and it is a
library.  In no way what-so-ever, can it be called a portability project.

As for apr-util, since it's creation, we have added some code that acts
as glue code for disparate back-ends.  That can be considered portability
code, so maybe it should stay.  I don't know.  What I do know, is that
apr-util is not a useful library.  Not because it doesn't have useful
code, but because there is nothing tying the code together.  

Try asking yourself the question:

When would you recommend that somebody look into using ____?

APR:
	If they need to write portable C code.

APR-iconv:
	If they need to write portable C code in that deals with multiple 
charsets.

APR-util:
	I haven't got a clue.  If they need one interface to a lot of
DBs?  One interface to an XML parser?  One interface to data stores?  If
you have a modular program and want some cool macros?  What is the
underlying goal of this code base?  If it is to create some cool routines
for Apache, then put it in Apache.  If it is to be glue code for disparate
backends, then remove everything that doesn't fit that goal, and keep in
APR.

APR-serf:
	If they need access to a portable HTTP client library.

Notice that APR-util and APR-serf don't help you write portable
code.  They are inherntly portable.  That isn't APR's goal, and it never
was.  If you want it to be the APR project's goal, then make that the
goal, but that isn't the way the vote is leaning.  However, that is the
goal for commons, so the packages belong there.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	[email protected]
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------