>> 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.


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

Reply via email to