> On Sep 25, 2007, at 6:31 AM, Joshua Megerman wrote: >> Perhaps the first step is to document the API as it currently >> stands, and >> give people the option to build a shared library with the caviat >> that if >> you reconfigure vpopmail, you need to rebuild those things that link >> against it. That would be a 5.5 branch, since it doesn't change the >> current functionality (much). Then we can in parallel start >> developing >> the truly stable API and other changes that will become 6.0, and >> when we >> do we can increment libvpopmail.so to indicate the ABI difference. > > I would love to see this happen, but it is going to take a > considerable amount of work. I'm willing to provide lots of input on > the API, but really don't have time to contribute actual code. > I know the feeling...
> I can help out with documenting some of the ways that QmailAdmin > interfaces with vpopmail. Getting a new version of QmailAdmin to > compile to a shared vpopmail lib with a single vpopmail.h to describe > the API would be great. As it is now, QmailAdmin actually uses > vpopmail's config.h file at build time. That will definitely have to > go. > Yes, that would be a good step. One of the things that I think needs to be identified is all of the packages that we know of that interface with libvpopmail, and how they do so. That will help us develop the new API so that we can provide all of the necessary program interfaces. > If we use two different names, could we retain backward compatibility > by building a libvpopmail the way we do now (statically linked, apps > may use vpopmail's config.h, etc.) in addition to the new-style, > shared library with a well-defined API? > I don't know enough about how shared vs. static libraries work at a system/compiler level, but I would think this could work. However, I think long-term we want to eliminate the old-style API through the static library just for ease of maintainability. But I don't see a problem with generating both shared and static libraries, and letting the person compiling the package that uses them decide which one to use. Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]