Matt Brookings wrote:
Hash: SHA1

Rick Widmer wrote:
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.

Sorry, it has been a long time since I've looked at the code. There are ifdefs that change how you interact with libvpopmail, I don't remember exactly where. Maybe it is in structs. I would have to do some research to figure out what bothers me so much. It is something about how various ./configure options change how the daemon interface works from the client end. You should be able to write a vpopmaild client without knowing what the ./configure options for vpopmail were.

The number of ./configure options that control ifdefs in the code requires testing an exponential number of different settings if you want a complete test suite. Less is better. Much better!

  -- At least with 'if based 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.

At least in MySQL and Postgress we are already reading a configuration file to get the database login information. Both vchkpw and vdelivermail are already opening the file every time they run. Search for 'load_connection_info()'. All of the back-ends provide it, not all of them actually open a file, but it does give you a chance to initialize things.

On some supremely busy systems, couldn't this potentially add to existing
disk bound I/O wait?

Yes, but long ago it was decided that having the database info in a file was needed. I figure that since we are already opening and reading the file adding a few more items in the file won't cost that much more.

I've run vpopmail on a 486 server, so I appreciate the 'lean and mean' ideals in the design of vpopmail, but by the end of the discussion on configuration files I was convinced that times have changed. If you are willing to connect to a database and run a query, reading a config file is nothing.

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

Well then my request is: don't add ./configure options and the resulting ifdefs, and remove them where possible. Turn it on, and let people who don't want quotas default them to unlimited. Code it so unlimited is fast and call it good.

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.

I'd say vpopmaild is a pretty good start. I was working on a PHP extension to access vpopmail when Ken announced the daemon. I took one look and found that it took care of all of the things that were impossible do do in the PHP extension. I did some debugging and wrote a PHP library to access vpopmaild, then I wanted more.

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 see it as a work in progress. The goal is that vpopmaild provides a remote way to do anything you can do from qmailadmin. The plan is to move code from qmailadmin to libvpopmail, then provide a way to call it in vpopmaild. Valias was first, ezmlm is in progress. I'm not sure what is left, but qmailadmin's capabilities are the standard to work on first.

Adding support to qmailadmin for the vpopmail daemon is a large project, and 
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 

Yes, but please consider the long range goal when deciding where to code something.

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 
with my coleagues over here, to the community, and see what everyone thinks.

I think what you are planning before the discussion all fits in the 5.4 branch. There definitely needs to be a final feature complete, debugged end to the 5.4 branch. One of the discussion topics can be what the next version should be.


Reply via email to