>> 1) A shared library with a stable API would make recompiling outside >> programs (e.g., QmailAdmin) unnecessary, which would be a Good >> Thing(tm). > > It is that 'stable API' that is the killer. I know some ./configure > options change the interface to libvpopmail. I don't know which ones > they are. :( I do know if you change some of the options you can get > some spectacular failures if you forget to re-compile everything that > uses vpopmail. > Hmm... that's a good point, although AFAIK the API is "stable" with respect to what the functions do for any given config.h. But you're correct that until things are documented and "blessed" (not to mention creating some sort of "official" API change process for the future, even if it's assigning 1 person as the only authority on changes).
> Once upon a time vpopmail was designed to be quick and tiny. All > options were compiled in. Since then at least 3 of the back ends have > adopted a configuration file. Maybe it is time to look at moving most > of the ./configure options to a configuration file and have only one > vpopmail library interface for the entire life of a major (minor?) > version. > > Are we starting 5.5 or 6.0 if we change the library interface, and table > layouts? > Hmm... if we're talking about doing major changes to existing functionality, I'd call that a major version change, as you're going to break things when you upgrade if you don't follow through with the upgrade process properly. As far as the table layout changes, while I understand that it could improve performance some, I'm not sure if it's really that big a deal. I worked on a system with ~6.5K users that had no DB lag time whatsoever, but we also used master/slave mysql over 6-8 frontends at any given time. But again, I'd definitely call that a major revision change. 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'm not sure how much I can do to help with this other than ideas, testing and the occasional spurt of inspired programming, but I'm willing to do what I can. 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]
