Thanks for finding time to work on vpopmail! I wish I had more of it...
Matt Brookings wrote:
I'd be very interested in seeing the project moved over to Subversion. Does
anyone have any
input on this?
I agree moving to Subversion is a good idea. I was planning on only
doing bug fixes on version 5 and leaving it in cvs then starting version
6 in Subversion. The major change from 5 to 6 would be organizing the
existing code. I think a bit of refactoring before moving to Subversion
will make future work much easier. My plan was:
o Each back end should be in a separate directory, including some of
cdb. Each back end directory should have separate files for valias code,
vlog code and libvpopmail code. (Maybe others.) Much of cdb needs to
be available even with database back ends but the back end selection
should be done only with symlinks. [1]
o Eliminate as many ifdefs as possible. [2]
-- No ifdefs in the libvpopmail function headings.
-- At least with 'if vased on config file' vs. the existing
ifdefs you know all the code will compile.
-- Things like quota are always compiled in and given default
values that act like it wasn't there.
o qmailadmin should be a web interface that can run on top of either
libvpopmail or vpopmaild. If running on vpopmaild it does not have to
run on the web server.
o vpopmaild should be only an interface between the network and
libvpopmaild. All the work should be done within libvpopmaild.
o The code that does all the actual work that exists in qmailadmin
should be moved to libvpopmail to make the the switch between it and
vpopmaild as simple as possible. [3]
Rick
[1] For example valias code is in a file for mysql and postgress, but
within vpopmail.c and ifdef'ed out for the other back ends. Yuck!
Having each back end in a directory makes auditing the code easier. You
know there must be certain files, and they must provide a specific set
of functions. A back end can have additional files.
[2] Once upon a time vpopmail was proud that all options were compiled
in to make it as fast as possible but now that we are committed to
opening a configuration file in most back ends I'm afraid it has become
liability. I would not be surprised if there are combinations of
options that won't compile. I'm certain there are some that don't work
right. Too many patches that only considered one set of options. :(
[3] I've got the code for managing ezmlm separated from qmailadmin and
moved into libvpopmail. The last I worked on it I needed to define the
grammar that vpopmaild would use when creating or modifying a mailing
list. It's been a long time...
!DSPAM:496ed6b032675859489829!
