Well, I had originally decided not to answer these questions because Mr. Clements systematically found something he didn't like about nearly every point I made.
However, after thinking about it a bit, I realize that was a bad choice, and more than a little silly. I appologize. In the spirit of discussion, here goes: ----- Original Message ----- From: "Doug Clements" <[EMAIL PROTECTED]> To: "Jesse Guardiani" <[EMAIL PROTECTED]>; "vpopmail" <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 4:18 PM Subject: Re: [vchkpw] vpopmail extension modules > ----- 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? Well, yes and no. My point is that many successful projects release production code more quickly. > > > 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. No, not really. I didn't say that the vpopmail developer was answering MY question. The developer was replying to someone else's problem. My point here is that the developer had spent so much time in the development version code that he refers to the production release as 'back in the 5.2.x days'. That makes it sound like just a bit too much time has passed since a release, IMO. > > > 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. I haven't thought about this as much as I probable should have, but here are a few things off the top of my head: 1.) Individual authentication storage and access mechanisms would make good modules. (LDAP, MySQL, flat file, etc...) 2.) Possibly mailbox read write code might make a good module. (One for maildir, one for mbox, etc) 3.) Quota management might make a good module Maybe others too. But I'm not so much thinking about how badly I hate the current implementation of vpopmail (because I don't), but how we might make it easier to extend vpopmail in the future. And possibly take some load off the inter7 team in the process. Each non-standard module could have it's own mailing list and programming team, making development progress a bit faster, and also making code a bit easier to follow (because it's modularized). Also, I don't really believe in overengineering. What's the harm in thinking about how we might make things easier for ourselves in the future? > > > 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. Does GPL mean that you absolutely HAVE to distribute and publish your code? (I don't think it does... I could be wrong though...) (Under the assumption that I'm not wrong...) So, if a programmer makes a module for a company under the GPL, he has to give that company his code. But that doesn't mean he has to make it public domain, does it? (Man, I hope I'm not sticking my foot in my mouth. This is just a regurgitation of my limited knowledge of the GPL) > > > 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). Sure. So what? Every time inter7 adds anything to vpopmail it slows down a little bit. That's generally what happens when a program grows. I don't think modularization would slow it down enough to matter to most people. And if it did, we could always daemonize vpopmail. (Please, no comments) > > > 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. Well, I guess this goes back to the assumption that I really really want to give EVERYONE my code. If I don't, I have to rewrite my patch every time a new version is released. I like the GPL too people, but I'm not going to give you the credit card number I enter into my GPLed online shopping cart. Some things need to remain secret sometimes. (Again, maybe I don't understand the GPL well enough though.) > > What exactly are you getting at? My ultimate point is that it would be really cool, IMO, if vpopmail had a module API like Apache. That way, people could write new quota code, new integration code with whatever they want, and new database code without necessarily bothering the inter7 folks all the time. It would be even cooler if this module API allowed new vpopmail modules to add their own administrative interfaces in qmailadmin and vqadmin without actually touching qmailadmin or vqadmin code. Thanks for replying! And thanks for reading! Jesse > > --Doug > > >
