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. 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 server! 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 developers. 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) http://www.wingnet.net 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.
