-----BEGIN PGP SIGNED MESSAGE-----
Rick Widmer wrote:
>> 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.
You make an extremely good point here.
>> 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.
There won't be any configuration options. You either run the feature,
or you don't. If you don't run it, no quotas. If you run it, quotas.
It's always available and compiled in. That is the current status anyway :)
>> 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
>> 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
That is not actually the goal that we discussed internally for the vpopmail
daemon. It kind of took that turn as the community had the hand in development
of it. The vpopmail daemon was to only provide remote calls to the vpopmail
API. Further commands, such as ezmlm management, etc, should never have been
a part of the vpopmail daemon itself, but extensions of it (modules, etc).
It is what it is, and it's being used as it is, so I don't see it changing.
It's good the feature is there, even if it's not strict to package hierarchy
>> 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
> Yes, but please consider the long range goal when deciding where to code
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
-----END PGP SIGNATURE-----