----- Original Message ----- From: "Jesse Guardiani" <[EMAIL PROTECTED]> To: "Doug Clements" <[EMAIL PROTECTED]>; "vpopmail" <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 6:47 PM Subject: Re: [vchkpw] vpopmail extension modules
> > 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 think vpopmail is unique in that it's very specialized and very small. There haven't been huge changes that require the more frequent updates other software packages have. While there are some bugs, they aren't usually very big, and since most of vpopmail is buffered by other software from potentially malicious users, the fixes typically aren't earth-shattering. New features aren't added often either, so there just doesn't seem to be much demand for more regular updates. While I think they could be a bit more often, making releases just because it feels like it's been a long time is not a good reason. Look at qmail, which hasn't had an official update in years. (On the flip side, look at the collections of patches that people have submitted for enchanced functionality and bug-fixing). > 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. Gotcha. I stopped running a "stable" release a long time ago, so I guess I'm a bit insulated from that. > 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 1) I think that authentication methods are generally just so darn simple that there's no incentive to go through the trouble of modulerizing. For any storage method you want to use, there's going to be easy-lookup and easy-update routines, which takes minimal implementation in the clients. You're also only going to be using one of these at a time on a given system, so it makes sense to compile it statically for the above reason as well as the minimal speed increase. Now if you wanted to for some reason mix authentication backends, there's potential. I can't come up with a real-world scenario for that off the top of my head, though. 2) Same argument for using only one at a time, with these exceptions: - Boxes with users that use different formats * but: vpopmail users are virtual, so users don't care what format their mailbox is in - I currently pass off mail delivery to Maildrop. I think you can also pass it off to procmail (if you really want mbox). This is already modular enough to pick the 2 most popular delivery and filtering mechanisms out there, in addition to straight delivery without filtering. 3) You mean lookup and setting of quota, or calculation? lookup and setting should go along with whatever authentication backend you use. Calculation pretty much depends on the mail storage format you use. I personally do quotas with Maildrop, which dropped in to replace vdelivermail with a little scripting. Now that vdelivermail does Maildir quotas and has .qmail file support, I think I'll change it back. From my view, the parts that need to be modular already are. > 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). Modularization does not automatically make code easier to follow. In fact, in this case, I think it would be harder. > 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? No harm there. I think there are areas in which vpopmail could get better, I just don't think that modularization fits into how vpopmail works at this time. You typically pick one thing out of a list of choices and don't run different choices concurrently. > Does GPL mean that you absolutely HAVE to distribute and publish your code? (I don't think it does... I could be wrong though...) If you change vpopmail (or any other GPL-licensed code), yes, you have to make it available to the public. > (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) public domain is not GPL. GPL is a virus that requires distribution of modified code. If the module is licensed under the GPL, it must be made available, yes. You can technically get around the GPL with certain types of modules, but this is where my knowledge gets fuzzy. Apparently things you link into a program count, but things that can be loaded at run-time don't count. This is how you can license a linux kernel module under some other non-gpl license, and run gcc on non-GPL systems. Create the module statically in the kernel, however, and it falls under the GPL. > > 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) Things are being added at a very slow pace, and the things that aren't being used can be compiled out. The overheard of modularization in that way I think you want to do it is unavoidable. > 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.) The GPL does not cover data created or processed with GPL-licensed software, as far as I know. > 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. I don't think the project is large enough with a large enough volume of change to warrant the trouble. --Doug
