On Mon, Nov 04, 2002 at 02:22:28PM -0500, Ryan Bloom wrote: > > 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.
It has been obvious from the beginning that you were not interested in having Serf in APR, and that's fine. I would be fine with moving it too once we know 1) why we are moving it 2) from where it is coming (why it doesn't fit in APR) 3) to where it is going (why it fits in Commons) None of those have been answered, let alone come to a consensus on. > 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. +1 > Then, we created apr-iconv. A project whose goal is to allow portable > codepage conversion. That project should stay, because it is about > portability. +1 > 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. The point of Serf is not just to create an HTTP Client library. It must also be portable. I agree that this doesn't align perfectly with the goals of APR, but it is false to say it is not about portability when it is one of the main overriding goals. > 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. +1 > 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. I totally agree with almost all of the points you have made above. I'm simply asking for us to draw the lines and make the boundaries BEFORE we go kicking code and projects around. Fine, go ahead and remove SERF from APR, but don't be surprised if APR is suddenly subsumed into Commons. -aaron
