Tom Collins wrote:
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 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 would start with the things that qmailadmin calls, then add any additional things that vpopmaild calls. (They should be very close in their use of the vpopmail api) That is the api, and everything else is considered internal, and subject to change. At that point give the general users a chance to ask for anything else they need in the api.

As far as that goes, vpopmaild commands exploit pretty much everything I consider the vpopmail api. (If something is found missing from vpopmaild it should be added.) Re-state the vpopmaild documentaton in C terms and you are close.

Tom Collins wrote:
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?

The difference between shared and static libraries isn't in the code. It is all compiler options and when the linking actually happens. The problem as I see it is ./configure options like --enable-clear-password. This option changes the table definition in sql back ends, and the structure of the vpasswd and vpasswd.cdb files in the cdb back end. It may even change the struct that contains the password data.

The solution as I see it is to compile with everything on, disable undesired options at runtime based on the configuration file, and always provide variables and fields, even for disabled items, when library functions are called.

John Simpson wrote:
>>On 2007-09-24, at 1120, Joshua Megerman wrote:
2) There has been some question regarding performance of the vpopmail
programs when compiled against shared vs. static libraries.  I suggest the
following options be added for shared libraries at compile-time:
  a) --disable-shared - don't build, which is what vpopmail
does now.
  b) --enable-shared - build, but don't link the vpopmail
binaries against it - this gives other programs the ability to use the
shared library, but keeps the vpopmail binaries statically linked.
  c) --enable-shared-binaries - build and link the vpopmail
binaries against it.  Implies --enable-shared.
  d) possibly, if it's not to difficult, have a --enable-shared-binaries=
and/or --enable-static-binaries= option, which takes a list of binaries
to link against the stated library, and links the rest against the
other.  So you could have static vdelivermail and vchkpw, but not
vadduser, for example.  Not sure if that really is necessary, but static
linking does save space...

i vote for "a" and "c" during a transition period, then "c" as the only option 
after that.

I agree with a and c, but think the option should stay forever.

in either case, i think "d" might be taking the idea too far.

I agree.

I disagree that static links save space. Each static executable contains all of the library code, so there are many copies. On the other hand, I use static binding for key programs so I don't have to worry about updating the central library. Replace the programs and the correct library is right there in the files.

If so, perhaps the speed solution for a dynamic
(e.g.) vdelivermail would be to run something that was dynamically linked
all the time, so libvpopmail stayed in memory...

if you're on a system which is busy enough that these few milliseconds are
> a significant issue, you will already have tens or hundreds of other
> processes with mapped into their memory space anyway- so
> again, it won't be an issue.

Like vpopmaild.  Once you fire that up libvpopmail should stay in  memory.

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

add a vpopmail_init() function which reads that file and sets a bunch
> of "use_*" variables, which the other functions would then check. make
> it a requirement that all client programs must call this function first,
> or any functions whose operation depends on these variables being
> properly set, could call this function instead... of course it would have
> a flag variable so that calling it multiple times doesn't result in the
> config files being read multiple times, something like this...

There is already a function vauth_open, which may be a no-op for some back ends. The documentation should say you MUST call it before doing anything else with the library. (I thought it already did.) The library should probably abort if anything is called before vauth_open.

I know all the back ends have had this added (even if I broke the code and no one has discovered it yet...) and I modified qmailadmin to use it for all back ends a couple of years ago. (If we run across a back end that doesn't compile and hasn't been updated for years, maybe it can be deleted.)

the other suggestion i have is this- there are options which make sense
> for larger systems, and don't hurt anything for smaller systems, the ones
> involving splitting the domains and mailboxes into numbered sub-directories
> in order to prevent having a single directory with 15,000 entries in it.
> these options should just plain be turned on for everybody, and the "options"
> should be removed.

the only argument i've ever heard for keeping them as options is that some
> people have written scripts which make assumptions about the directory
> structure. these scripts should run "vdominfo -d" and "vuserinfo -d" to get
> the directories, rather than assuming they will be in any particular
> location. i'm just not a fan of hanging on to options which serve no purpose > other than to accomodate improperly written scripts- the idea of splitting > the domains and mailboxes into different directories has been around forever,
> there's no excuse for somebody to not have made the adjustment by now.


Joshua Megerman wrote:
Anyway, that's it for now - I haven't even tried the patch against the
>> latest vpopmail, though I'm guessing it should be fairly easy (albeing
>> possibly tedious) to integrate since it's not much in the way of
>> actual
>> code changes...
> if you have a URL for that patch, i'd like to play with it myself.
It's on the vpopmail SF page, under feature requests.

And on my list for inclusion after we get a good stable version out to keep the users happy.

the idea of splitting the domains and mailboxes into different
>> directories has been around forever, there's no excuse for
>> somebody to not have made the adjustment by now.

I'm all for keeping it, but someone should fix it.  On my server,
> with a cdb backend, I have the following structure:

That one is on my list too.

my suggestion would be to use 5.5 as the "testing ground" as we
> migrate closer to a single API and a shared library, with 6.0
> being the "release" with a shared library only.

OK, I won't start anything yet... I am partial to 6.0 being dev and 6.1 being stable. If we unify the library interface and change the database structure it is a major change.

Reply via email to