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 

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 
desirable either.

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 
than that.

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.

Reply via email to