On 02 Jun 2011, at 1:27 AM, Greg Stein wrote:
You're just talking about bringing back apr-util.
Pretty much, without the "lump it all together in apr-util".
Making these N different packages doesn't do much beyond just what the old apr-util did. I guess it solves a bit of dependency stuff.
I disagree, it goes a lot further - it solves the problem of what to do if an API is proposed for APR that is simply too big for the library.
At this point we have no "escape valve" to protect us against code bloat. Our only option at the moment is to keep adding stuff to the core apr project, or just rejecting code with the explanation "we're full, go away". Neither of these are healthy options.
Personally, I gave up on the "combined vs split" argument a long time ago. This community wanted to combine everything, and I felt differently. It happens. I also felt that APR has got a lot of old, clunky code that needs to be cleaned up. As a result, I started my PoCore project to deal with just the low-level portability concerns, with a full revisit of all the concepts based on experience with APR, HTTPD, svn, and serf. High-level stuff can be left to applications or other third-party libraries.
If people are starting their own portability libraries, then it shows that apr is not fit for purpose in its current form, and that needs to be addressed by the apr project. I don't recall much discussion happening over "combined vs split", suddenly we were combined, and as I recall nobody provided an explanation as to what problem they were trying to solve by doing so.
It seems what we're working towards is combining apr and apr-util, removing most of the stuff that was in apr-util, ending up pretty much back with apr, which leads me to ask why we ever bothered combining the two in the first place.
Regards, Graham --
