-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rick Widmer wrote:
> 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:
Due to the way the conversion process on SourceForge works, I think it would
probably be better to convert the entire project to Subversion, and then make
any changes.
Changes like the ones you're describing would probably require a branch so that
other development could continue.
> 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]
That would indeed be a good manner to clean up the source tree's look.
All the README files clutter as well.
> o Eliminate as many ifdefs as possible. [2]
>
> -- No ifdefs in the libvpopmail function headings.
I'm not sure what you're referring to here.
> -- At least with 'if vased on config file' vs. the existing
> ifdefs you know all the code will compile.
Oh, you mean have a config file that vpopmail reads, and all features
are compiled in? I'm not sure that's such a good idea. While vchkpw could
potentially be left out of the configuration file idea because it simply
does authentication, vdelivermail would need to read the configuration every
time it was invoked.
On some supremely busy systems, couldn't this potentially add to existing
disk bound I/O wait?
> -- Things like quota are always compiled in and given default
> values that act like it wasn't there.
I'm currently reworking the entire quota system. I'm working on some POC
code to partially replace as well as add on to the existing quota code.
It will provide user and domain quotas, as well as fix the current issues
between vpopmail, large quota sizes, and the web interfaces that interact
with it.
That, aside from proper maintenance of the vpopmail, and eventually,
qmailadmin, and vQadmin projects, is my main development project right
now.
> 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.
When I first started working for Inter7, about 10 years ago, I brought up the
idea of RPC for vpopmail. It was not initially taken as a feature that was
worth developing at the time due to the fact that there were so many base
features to add, and many bugs to fix.
I can't say that the vpopmail daemon is anything like I would have written it.
It seems more of a kludge of features added randomly, with no real management
as to how commands are made available to it. I would have modularized it,
and in the end, it would have been used for this quota system.
Adding support to qmailadmin for the vpopmail daemon is a large project, and
while
I definitely see the value in it, I think the changes vpopmail should go through
will need to be priority one mostly because qmailadmin will need to take up
these
changes.
Once I get settled in and have most of the bugs and patches settled, some new
versions tagged, etc, I'm going to present some changes to vpopmail that I've
discussed
with my coleagues over here, to the community, and see what everyone thinks.
> 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]
Ditto from above.
> [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...
These are all very interesting ideas, and I think we should keep these in mind
as we move ahead.
Thanks for your input, Rick.
- --
/*
Matt Brookings <m...@inter7.com> GnuPG Key D9414F70
Software developer Systems technician
Inter7 Internet Technologies, Inc. (815)776-9465
*/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJb1LK6QgvSNlBT3ARAsZcAJ47WPJhhJ8lxWctcC6CjpaoBQGzyQCfRjHZ
9kuGLdCcDMFVyeSjy9VP2wI=
=rqcp
-----END PGP SIGNATURE-----
