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

Reply via email to