Greg Stein wrote:
Portable across *libraries*I always associate "portable" with operating systems. Not using different APIs. Personally, I'm finding it a little weird that APR is in the business of creating common APIs for third-party libraries.
Portability crosses OSes, it crosses different versions of OSes shipping different versions of the same library, and it crosses different implementations of the same functionality provided on different OSes. The general test I think should be applied for "does it fit in the set of APR projects" is "does functionality X involve the jumping through of many system specific hoops before it works on both system A and system B". The more specific test of "does it belong in apr proper" could be "does the functionality make portable that requiring only libraries that could realistically be expected to be found natively on most of the systems covered, like libc or the the socket libs where not included in libc".
Well, the discussion has been about folding all the libraries into one, so I'm not sure people will be willing to create another :-P
Fair enough, in that case, fold the apr-util stuff that isn't modularised into apr, and leave apr-util to be the modularised libraries themselves. :) I don't see any problem with APR creating common APIs where no common API exists (dbd, crypto), or adding common APIs where people have tacked on incompatible extensions to an existing standard API (LDAP + TLS/SSL). The common APIs exist because there is a need for them. Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
