----- Original Message -----
From: "Jesse Guardiani" <[EMAIL PROTECTED]>
To: "Doug Clements" <[EMAIL PROTECTED]>; "vpopmail"
Sent: Sunday, February 23, 2003 6:47 PM
Subject: Re: [vchkpw] vpopmail extension modules
> > Most software development goes like this. I would be dissapointed at
> > if they didn't have development and stable releases. Why do you want
> > code in a supposedly "stable" distribution?
> Well, yes and no. My point is that many successful projects release
production code more quickly.
I think vpopmail is unique in that it's very specialized and very small.
There haven't been huge changes that require the more frequent updates other
software packages have. While there are some bugs, they aren't usually very
big, and since most of vpopmail is buffered by other software from
potentially malicious users, the fixes typically aren't earth-shattering.
New features aren't added often either, so there just doesn't seem to be
much demand for more regular updates.
While I think they could be a bit more often, making releases just because
it feels like it's been a long time is not a good reason. Look at qmail,
which hasn't had an official update in years. (On the flip side, look at the
collections of patches that people have submitted for enchanced
functionality and bug-fixing).
> My point here is that the developer had spent so much time in the
development version code that he refers to the production release
> as 'back in the 5.2.x days'. That makes it sound like just a bit too much
time has passed since a release, IMO.
Gotcha. I stopped running a "stable" release a long time ago, so I guess I'm
a bit insulated from that.
> 1.) Individual authentication storage and access mechanisms would make
good modules. (LDAP, MySQL, flat file, etc...)
> 2.) Possibly mailbox read write code might make a good module. (One for
maildir, one for mbox, etc)
> 3.) Quota management might make a good module
1) I think that authentication methods are generally just so darn simple
that there's no incentive to go through the trouble of modulerizing. For any
storage method you want to use, there's going to be easy-lookup and
easy-update routines, which takes minimal implementation in the clients.
You're also only going to be using one of these at a time on a given system,
so it makes sense to compile it statically for the above reason as well as
the minimal speed increase. Now if you wanted to for some reason mix
authentication backends, there's potential. I can't come up with a
real-world scenario for that off the top of my head, though.
2) Same argument for using only one at a time, with these exceptions:
- Boxes with users that use different formats
* but: vpopmail users are virtual, so users don't care what format their
mailbox is in
- I currently pass off mail delivery to Maildrop. I think you can also pass
it off to procmail (if you really want mbox). This is already modular enough
to pick the 2 most popular delivery and filtering mechanisms out there, in
addition to straight delivery without filtering.
3) You mean lookup and setting of quota, or calculation? lookup and setting
should go along with whatever authentication backend you use. Calculation
pretty much depends on the mail storage format you use. I personally do
quotas with Maildrop, which dropped in to replace vdelivermail with a little
scripting. Now that vdelivermail does Maildir quotas and has .qmail file
support, I think I'll change it back. From my view, the parts that need to
be modular already are.
> Maybe others too. But I'm not so much thinking about how badly I hate the
current implementation of vpopmail (because I don't), but
> how we might make it easier to extend vpopmail in the future. And possibly
take some load off the inter7 team in the process. Each
> non-standard module could have it's own mailing list and programming team,
making development progress a bit faster, and also making
> code a bit easier to follow (because it's modularized).
Modularization does not automatically make code easier to follow. In fact,
in this case, I think it would be harder.
> Also, I don't really believe in overengineering. What's the harm in
thinking about how we might make things easier for ourselves in
> the future?
No harm there. I think there are areas in which vpopmail could get better, I
just don't think that modularization fits into how vpopmail works at this
time. You typically pick one thing out of a list of choices and don't run
different choices concurrently.
> Does GPL mean that you absolutely HAVE to distribute and publish your
code? (I don't think it does... I could be wrong though...)
If you change vpopmail (or any other GPL-licensed code), yes, you have to
make it available to the public.
> (Under the assumption that I'm not wrong...)
> So, if a programmer makes a module for a company under the GPL, he has to
give that company his code. But that doesn't mean he has
> to make it public domain, does it? (Man, I hope I'm not sticking my foot
in my mouth. This is just a regurgitation of my limited
> knowledge of the GPL)
public domain is not GPL. GPL is a virus that requires distribution of
modified code. If the module is licensed under the GPL, it must be made
You can technically get around the GPL with certain types of modules, but
this is where my knowledge gets fuzzy. Apparently things you link into a
program count, but things that can be loaded at run-time don't count. This
is how you can license a linux kernel module under some other non-gpl
license, and run gcc on non-GPL systems. Create the module statically in the
kernel, however, and it falls under the GPL.
> > Please realize that any speed hit is going to be multiplied by every
> > checking their mail (every 10 minutes) and for every mail delivery (of
> > we have many hundreds of thousands in a day).
> Sure. So what? Every time inter7 adds anything to vpopmail it slows down a
little bit. That's generally what happens when a program
> grows. I don't think modularization would slow it down enough to matter to
most people. And if it did, we could always daemonize
> vpopmail. (Please, no comments)
Things are being added at a very slow pace, and the things that aren't being
used can be compiled out. The overheard of modularization in that way I
think you want to do it is unavoidable.
> Well, I guess this goes back to the assumption that I really really want
to give EVERYONE my code. If I don't, I have to rewrite my
> patch every time a new version is released. I like the GPL too people, but
I'm not going to give you the credit card number I enter
> into my GPLed online shopping cart. Some things need to remain secret
sometimes. (Again, maybe I don't understand the GPL well
> enough though.)
The GPL does not cover data created or processed with GPL-licensed software,
as far as I know.
> My ultimate point is that it would be really cool, IMO, if vpopmail had a
module API like Apache. That way, people could write new
> quota code, new integration code with whatever they want, and new database
code without necessarily bothering the inter7 folks all
> the time.
I don't think the project is large enough with a large enough volume of
change to warrant the trouble.