Why? Maintenance cost. Plain and simple. Is APR truly used on these other platforms? I've gotta believe there is some data on that somewhere.
Then, there is the age-old answer, "those edge cases can stick to APR 1.x and HTTPD 2.x." Modern operating systems would use APR 2.x and HTTPD 3.x. Cheers, -g On Fri, Jan 23, 2009 at 13:24, Ryan Bloom <[email protected]> wrote: > Why do you want to jettison "edge platforms"? The original goal was to keep > HTTPd as portable as 1.3 was, which meant APR had to support mainframes, > OS/2, etc. All of those edge platforms are what made APR challenging to > create and maintain, but they also provide a lot of value for the people who > want their code to work on mainframes, but don't want to write their own > portability library. > > Removing this support takes away a web server (at the very least) from > openBeOS, OS400, OS/2, etc. While these platforms may not be mainstream > these days, dropping support for them from HTTPd (the natural result of > dropping support from APR) seems like a decision that can only be made after > discussion with APR's users, not the developers of APR itself. > > Just a few thoughts from the gallery. > > Ryan > > Ryan Bloom > [email protected] > [email protected] > [email protected] > > > On Fri, Jan 23, 2009 at 6:26 AM, Graham Leggett <[email protected]> wrote: >> >> Greg Stein wrote: >> >>> When thinking about 2.0, I'm having a hard time with the idea of >>> pulling apr-util into regular apr. We've got a lot of stuff in >>> apr-util that has nothing to do with "Portability". Basically, I see >>> apr-util doing one of two types of things: >>> >>> * common API to access functionality (dbd, ldap, crypto) >>> * useful functionality built on APR >>> >>> I think it would be great if we could concentrate on just a core APR >>> that offers OS portability, and that we also jettison "edge" platforms >>> (keep posix and windows only). And that we trim out functionality >>> (i.e. apr_tables) that have nothing to do with portability (tho we >>> keep pools as a lifetime mgmt capability for OS objects). >>> >>> Thoughts? >> >> I think both apr and apr-util are still both based on the idea of >> "portability". >> >> In apr, the focus is on making individual or "small" sets of functions >> available in a portable way, while the focus of apr-util is to have "large" >> or "complex" sets of functionality (access a database, access an LDAP >> server, encrypt a string) available in a portable way. >> >> That said you're right that some parts of it, like tables, fall into the >> category of "useful stuff" rather than "portable stuff". Perhaps an idea >> could be to move the "useful stuff" into (a want for a better name) >> apr-useful, which would be the "useful stuff" library built on top of the >> portability provided by apr. >> >> Regards, >> Graham >> -- > >
