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
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.
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
So... I was trying to think of ways to narrow this rift. Obviously, the development
cycle could change, but that is probably not
realistic. I've heard that inter7 dislikes CVS. And the entire vpopmail development
mentality would have to shift in order to
release development and production releases closer together. That's not necessarily
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.
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.
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
But we're talking about C here. I think the speed penalty could be kept at a minimum.
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.
Just add the module and the admin CGIs automatically include the necessary
functionality to interact with vpopmail.
Consider this email in the spirit of an RFC (Request for Comments).
I'm just thinking aloud, but I would genuinely like to here everyone's opinions on the
subject. Especially those of inter7
Thanks for reading!
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v) 423-559-5145 (f)
We are actively looking for companies that do a lot of long
distance faxing and want to cut their long distance bill by
up to 50%. Contact [EMAIL PROTECTED] for more info.