----- Original Message -----
From: "Jesse Guardiani" <[EMAIL PROTECTED]>
To: "vpopmail" <[EMAIL PROTECTED]>
Sent: Sunday, February 23, 2003 10:34 AM
Subject: [vchkpw] vpopmail extension modules
> Greetings list,
> I've been thinking a bit about the architecture of vpopmail. It seems to
me that the inter7 team is pretty busy making a living.
> (which is totally understandable) And new production releases don't come
about very often.
> So what seems to be happening is that people who need new functionality
submit patches to the vpopmail list, and the new patch gets
> implemented in the development version.
> These people now choose to run the development version rather than the
production version, and a rift grows between the code base of
> the 'normal' users and the 'development' users.
Most software development goes like this. I would be dissapointed at inter7
if they didn't have development and stable releases. Why do you want test
code in a supposedly "stable" distribution?
> I recently saw someone who develops vpopmail write about how 'Back in the
5.2.x days' certain bugs existed, and these bugs are now
> fixed in the development version. This amazed me because I was STILL IN
the 5.2.x days. I was running a production version on my
Sounds like you need to upgrade.
> One solution I thought about was a sort of plugin module API. If new
functionality were put into modules rather than intergrated
> into the main codebase, development would be MUCH more flexible. And if
modules were developed in a way that multiple modules could
> be included to add just the functionality that the user needed, the code
base could still be kept minimal.
What extra functionality would you like to modulerize? Looking up a user's
password? That's probably a 50 line routine at the moment. You're
overengineering this entirely too much.
> In addition, companies would have the ability to create in-house extension
modules without feeling the need to release them into the
> public domain. (And inter7 could create these modules for special
customers at extra charge) Currently, anything planned for use in
> the long term MUST find it's way into the vpopmail source code, otherwise
countless man hours will have to be wasted patching the
> source for each release.
inter7 licensed vpopmail under the GPL, so I don't think this is the
direction they wanted to take it. For the record, I've never had to spend
countless wasted hours patching the source for any release at all.
> Sure, this type of architecture would probably slow vpopmail down a little
bit. I mean, lets face it, anything that uses vpopmail
> right now just statically links in the vpopmail library. You can't get
much faster than that.
> But we're talking about C here. I think the speed penalty could be kept at
Please realize that any speed hit is going to be multiplied by every user
checking their mail (every 10 minutes) and for every mail delivery (of which
we have many hundreds of thousands in a day).
> The module architecture could even be developed with self-descriptive data
types that explain how to interact with a given module,
> making rewrites to the qmailadmin and vqadmin CGIs unnecessary.
If you really want a module, create a new configure option that enables or
disables a hook to whatever you want to implement in your code. It's a few
line patch to the main distribution, and you can modify your code all you
What exactly are you getting at?