Matt Brookings wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
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.
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
discussed
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.
!DSPAM:4970f63632671671619623!
