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!

Reply via email to