I largely think that I already have my answer from the vpopmail community regarding a module interface. Most of you don't think it's needed, or that it would be a benefit if it were written. And certainly I'd have to write it myself if I really wanted it that badly.
So, the following comments are written just to clarify some of my reasoning, NOT the say, "Hey! I want a module interface and I want it NOW!" On Tuesday 25 February 2003 03:06, Doug Clements wrote: > ----- 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 <snip> > > 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). I'm not sure that qmail is a good example. Half the crowd wants new patches incorporated, and the other half wants to make sure that their code stays small and fortified for security reasons. Vpopmail doesn't really have that many security issues (but it WOULD if someone daemonized part of it... which seems less useful now than when I originally thought of it) by design. > > > 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. That was kinda my point. Not many people run stable versions. It's kinda like the 'introductory' version of vpopmail. Then you step up to a development version if you need a new feature. (And there a quite a few to choose from) <snip> > Modularization does not automatically make code easier to follow. In fact, > in this case, I think it would be harder. Depends on how it's implemented, and how well it's documented. I used to be a Windows programmer. The one thing I really miss about windows is the excellent interface documentation. You just don't get that with UNIX. You have to dig for information yourself and get your hands dirty. A well written and well documented module interface might actually make it easier to write code for vpopmail. The only thing that worries me is that I fear much of the way vpopmail works would have to be modified to accomodate such a module interface. Vpopmail would probably have to take many aspects of a code library... > > > 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. I know we're going in circles at this point, but modularization would allow developers OTHER than vpopmail create modules that could be statically or dynamically linked to vpopmail. This removes inter7 from the loop, which I think would be a good thing. I dislike patches. (Yes, I know, I'm going to get flamed for choosing qmail now) > > > 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. Ouch. Didn't realize that. GPL is quite viral then isn't it. Well... what does "public" mean? If someone asks for it that I have to give it to them? What if no-one knows about it? Does the GPL list WHERE and HOW I have to make it "public"? Very confusing. <snip> > 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. I read a book about Open Source lately. The guy who wrote it was some kind of licensing guru. He mentioned that the whole dynamic and static linking issue was kinda fuzzy. Maybe if I wrote the modularization code I could get away with not telling anyone I wrote a dynamically linked module. I'll have to look into the amount of work my module interface would require. <snip> > 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. I'm not so sure about that. C is C is C. If you write it correctly, it'll be fast. A little abstraction won't totally kill vpopmail's speed. Besides, the vpopmail developers are still finding bottlenecks as is. I remember reading just a month or so ago about a multiple disk read problem that was solved by a patch, and when the patch was implemented the programmer's CPU went from 98% utilization to 98% idle. Sounds to me like optimization would be the name of the game. And besides, maybe this module interface could be written to be an optional feature. (Granted, a massive optional feature) <snip> > The GPL does not cover data created or processed with GPL-licensed > software, as far as I know. I know. I was trying to make a point. Just because I use your software doesn't mean I want to tell you everything about the way I use it. I realize that this may be tough to accomplish with the GPL though. <snip> > I don't think the project is large enough with a large enough volume of > change to warrant the trouble. Or maybe developers are scared off by the current development cycle and the current vpopmail architecture? A module interface might allow C coders to write new features for vpopmail without having to comprehend the ENTIRE source tree, the way they do now. > > --Doug -- 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.
