----- 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 > server! 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 a minimum. 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 want. What exactly are you getting at? --Doug
