Re: dbfunctions - it's over
Hi Ken, I in no way meant any bad feelings towards you. As I mentioned, I only came into this late in the game, so I only know what I see and hear, and from what people were saying, it sounds like they were screwed over. Doesn't mean they really were ;-) Anyway, you really don't have to convince me or sway me over to your side. Besides deploying vpopmail, I haven't spent much time actually developing anything on it. So the people that would need convincing are the developers themselves. I'm just here to try and help out a bit here and there, and try and make vpopmail a better product. Plain and simple :-) Sincerely, Jason - Original Message - From: Ken Jones [EMAIL PROTECTED] To: Jason Lim [EMAIL PROTECTED] Sent: Wednesday, May 30, 2001 5:37 PM Subject: Re: dbfunctions - it's over I guess I will respond. Jason Lim writes: Hi, I haven't been following the whole saga from the very start, so I won't claim to know absolutely everything... but it sounds like you just got screwed, plain and simple. I had no intention of screwing anyone over. I'm sorry if anyone feels like they were screwed over. I know someone else (I won't mention the name unless he wants me to) that has tried to submit patches and improvements, but no one listens. I know this guy's improvements and they really do help things, but why no one is co-operating with him, I do not know. The guy works with one of the largest Linux Distributions, so it is definately quality work. Anyway... maybe someone over at inter7 or something could explain why they choose to ignore all the developers out there trying to help and improve the products? Take a look at the AUTHORS file. It contains a list of people who have submitted code and enhancements. So it is not fair to say I have ignored *all* the developers out there. One thing you might want to consider before dragging me out and hanging me in the public square is that I work on vpopmail in my spare time. I am not paid to work on it. I don't want to release any code that has problems. So when I receive a patch or change, I want to review it and test it. It takes about 3 hours to completely test a change. I apologize to anyone who feels slighted or unhappy about how the vpopmail development is going. I try to do my best in managing this package. Oh well... Ken Jones Sincerely, Jason
Re: dbfunctions - it's over
Only for my curiosity, did you ask Ken, before writing, how could you be useful in order to extend vpopmail functionalities while remaining integrated with all the rest? Did he give you any rule to follow? tried aleast 3 times. i was never able to convince Ken to start open discussion about it. About your documentation, I visited http://members.elysium.pl/brush/vpopmail/ but I did not understand what your patches mainly do and why I should use them. Surely my poor english does not help me, but are you sure your documentation is well done and clearly understandable by other users/developers? Yes. The documentation is for c programmer. Beta testers had no problems. I do not anticipate any problems on Ken's side. Kris
Re: dbfunctions - it's over
Thanks for your reply. At 29/05/2001 29/05/2001 +0200, Krzysztof Dabrowski wrote: Only for my curiosity, did you ask Ken, before writing, how could you be useful in order to extend vpopmail functionalities while remaining integrated with all the rest? Did he give you any rule to follow? tried aleast 3 times. i was never able to convince Ken to start open discussion about it. I'm sorry. I would like to add other functionalities to vpopmail in the future, and I'll give a try with Ken, anyway. Let's see... About your documentation, I visited http://members.elysium.pl/brush/vpopmail/ but I did not understand what your patches mainly do and why I should use them. Surely my poor english does not help me, but are you sure your documentation is well done and clearly understandable by other users/developers? Yes. The documentation is for c programmer. Beta testers had no problems. I do not anticipate any problems on Ken's side. I'm a c programmer, but I read this kind of documentation as a designer who has to decide whether the patches are suitable for his needs or not. The c programmer side comes later, when I want to try them. I'm going to study/install/patch nothing if I have not clearly understood what the code was designed for. And I've not understood (as end user and main designer of my systems) what your patches are going to do. I think you should add a more wide and clear presentation of your patches and their goals before the c programmer documentation. Kris Tonino
Re: dbfunctions - it's over
"tonix (Antonio Nati)" [EMAIL PROTECTED] writes: This means there would be two different featured versions, one for SQL and one NOT-SQL, that's not exactly the result that someone trying to develop a portable, coherent, all features enabled product tries to achieve. It doesn't break the code, but it breaks the product. Not true, I think that everyone is welcome to add needed functionality to other backends using API defined by dbfunction patch. -- Ondej Sur [EMAIL PROTECTED]Globe Internet s.r.o. http://globe.cz/ Tel: +420235365000 Fax: +420235365009 Plnikova 1, 162 00 Praha 6 GPG fingerprint: CC91 8F02 8CDE 911A 933F AE52 F4E6 6A7C C20D F273
RE: dbfunctions - it's over
After examining your site. I am not understanding what your dbfunction patch does that the new development version of vpopmail does not do. Coming from a developers point of view the MySQL alias/forward that vpopmail now has in it looks to be very simple, easy to understand and easy to use (Table definition are simple and not confusing). Maybe the new vpopmail does do the same thing, however, Kris' patch did it for a long time before and many of us have applied thta patch and started to use it in large sites, as Ken had told us it was to be included! It now leaves many people with old versions of vpopmail not being able to upgrade because they have used the patch that was part of the distribution. I see no reason for taking Kris' out and writing a new one, and no such valid reason has been given to any of us.
Re: dbfunctions - it's over
From: Daniel Hardaker Sent: Tuesday, May 29, 2001 6:58 AM After examining your site. I am not understanding what your dbfunction patch does that the new development version of vpopmail does not do. Coming from a developers point of view the MySQL alias/forward that vpopmail now has in it looks to be very simple, easy to understand and easy to use (Table definition are simple and not confusing). Maybe the new vpopmail does do the same thing, however, Kris' patch did it for a long time before and many of us have applied thta patch and started to use it in large sites, as Ken had told us it was to be included! It now leaves many people with old versions of vpopmail not being able to upgrade because they have used the patch that was part of the distribution. I see no reason for taking Kris' out and writing a new one, and no such valid reason has been given to any of us. Sorry, the author always has the choice to keep producing the patch and distributing it. ezlm-idx comes in patch form why can't this? Here I will write a conversion program from dbfunction to the new valias then everyone can be happy in the future.. Sean Sean
Re: dbfunctions - it's over
From: Krzysztof Dabrowski To: [EMAIL PROTECTED] After examining your site. I am not understanding what your dbfunction patch does that the new development version of vpopmail does not do. Coming from a developers point of view the MySQL alias/forward that vpopmail now has in it looks to be very simple, easy to understand and easy to use (Table definition are simple and not confusing). My patch implements also a) command's calling from database (emulation of calling stuff from dot-qmail) This can be done in the recent development version of vpopmail. b) multiple aliases per account (simple small mailing lists without ezmlm) This can be done in the recent development version of vpopmail. c) pass-through aliases/forwards (store mail on aliased account AND copy to to the underlying account TOO). This can be done in the recent development version of vpopmail. Never mind. I gave up on this. I just do not want Ken to fell OK after telling lies in his post a month ago (breaking, no-docs etc.). Again tell me why your patch needs to be added to vpopmail? Remember, this time it's me. Next time it may be you. It's not wise to invest time in a closed product. Kris
Re: dbfunctions - it's over
vpopmail is GPL, no ? So it's possible for anyone to start an another project with the dbfunctions included from beginning and evolve to a separate product. Vpopmail is not a closed product. I have no time now to work on but perhaps in a few months, depending of our needs and the current evolution of vpopmail, this will be possible (we are starting soon a free web mail in Quebec, Canada). Is there somewehere a page with all patches and documentation related to vpopmail ? If not, I will setup one during the week. Benoit - Original Message - From: Krzysztof Dabrowski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 29, 2001 3:29 AM Subject: Re: dbfunctions - it's over After examining your site. I am not understanding what your dbfunction patch does that the new development version of vpopmail does not do. Coming from a developers point of view the MySQL alias/forward that vpopmail now has in it looks to be very simple, easy to understand and easy to use (Table definition are simple and not confusing). My patch implements also a) command's calling from database (emulation of calling stuff from dot-qmail) b) multiple aliases per account (simple small mailing lists without ezmlm) c) pass-through aliases/forwards (store mail on aliased account AND copy to to the underlying account TOO). Never mind. I gave up on this. I just do not want Ken to fell OK after telling lies in his post a month ago (breaking, no-docs etc.). Remember, this time it's me. Next time it may be you. It's not wise to invest time in a closed product. Kris
Re: dbfunctions - it's over
a) command's calling from database (emulation of calling stuff from dot-qmail) This can be done in the recent development version of vpopmail. b) multiple aliases per account (simple small mailing lists without ezmlm) This can be done in the recent development version of vpopmail. c) pass-through aliases/forwards (store mail on aliased account AND copy to to the underlying account TOO). This can be done in the recent development version of vpopmail. I see. And the only change log line about calling programs out of alias looks like this: Sending the email into a program isn't completed yet. :) Never mind. As i said, i do not want to convince you to anything. I have already GAVE UP - so do not try to convince me. Again tell me why your patch needs to be added to vpopmail? I wont repeat myself. I've spent more than half a year wating for Ken just to find out that my effort is wasted. Betatesters' effort was wasted. And all without a single trace of open discussion. Please do not bring it again, i do not want to discuss the political side of story again and again.
Re: dbfunctions - it's over
Hi, I haven't been following the whole saga from the very start, so I won't claim to know absolutely everything... but it sounds like you just got screwed, plain and simple. I know someone else (I won't mention the name unless he wants me to) that has tried to submit patches and improvements, but no one listens. I know this guy's improvements and they really do help things, but why no one is co-operating with him, I do not know. The guy works with one of the largest Linux Distributions, so it is definately quality work. Anyway... maybe someone over at inter7 or something could explain why they choose to ignore all the developers out there trying to help and improve the products? Sincerely, Jason - Original Message - From: Krzysztof Dabrowski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 29, 2001 10:16 PM Subject: Re: dbfunctions - it's over a) command's calling from database (emulation of calling stuff from dot-qmail) This can be done in the recent development version of vpopmail. b) multiple aliases per account (simple small mailing lists without ezmlm) This can be done in the recent development version of vpopmail. c) pass-through aliases/forwards (store mail on aliased account AND copy to to the underlying account TOO). This can be done in the recent development version of vpopmail. I see. And the only change log line about calling programs out of alias looks like this: Sending the email into a program isn't completed yet. :) Never mind. As i said, i do not want to convince you to anything. I have already GAVE UP - so do not try to convince me. Again tell me why your patch needs to be added to vpopmail? I wont repeat myself. I've spent more than half a year wating for Ken just to find out that my effort is wasted. Betatesters' effort was wasted. And all without a single trace of open discussion. Please do not bring it again, i do not want to discuss the political side of story again and again.
RE: dbfunctions - it's over
Anyway... maybe someone over at inter7 or something could explain why they choose to ignore all the developers out there trying to help and improve the products? Thats the problem, no one has made any effort to reply, and it destroys my confidence in such a fine product. I can see a new version being developed from here, possibly based on vpopmail or possibly not. Many people are very frustrated!
Re: dbfunctions - it's over
Sorry, but I don't agree. I don't know your product, Krzysztof, and I suppose your coding to be excellent, but I feel your vision is very close to your needs only. At 28/05/2001 28/05/2001 +0200, Krzysztof Dabrowski wrote: You can check the archives for the exact posting (subject Dbfunctions) but the general of it all was that dbfunctions could not be included in its current state because it breaks non database installations, it lacks documentation and Krzysztof never gave Ken enough information to port it properly to support the entire vopmail userbase. i gave up on this earlier, but to clarify some things to you (and maybe others). a) it does not BREAK anything, it's completely transparent for non-db instalation it's just added functinality for mysql version. You can switch it off while compilation and even if it's turned off, you do not have to use it at all. This means there would be two different featured versions, one for SQL and one NOT-SQL, that's not exactly the result that someone trying to develop a portable, coherent, all features enabled product tries to achieve. It doesn't break the code, but it breaks the product. b) there is full documentation including new api calls, data structures etc. on the website since the day zero. c) after the emails here NOBODY from inter7.com even bothered to check the mentioned website (http://members.elysium.pl/brush/vpopmail/) Please, try to verify your information before spreading lies. Kris Tonino
Re: dbfunctions - it's over
Krzysztof, After examining your site. I am not understanding what your dbfunction patch does that the new development version of vpopmail does not do. Coming from a developers point of view the MySQL alias/forward that vpopmail now has in it looks to be very simple, easy to understand and easy to use (Table definition are simple and not confusing). If I am wrong please let me know.. Sean Truman At Monday, May 28, 2001 6:39 PM From: tonix (Antonio Nati) Sorry, but I don't agree. I don't know your product, Krzysztof, and I suppose your coding to be excellent, but I feel your vision is very close to your needs only. At 28/05/2001 28/05/2001 +0200, Krzysztof Dabrowski wrote: You can check the archives for the exact posting (subject Dbfunctions) but the general of it all was that dbfunctions could not be included in its current state because it breaks non database installations, it lacks documentation and Krzysztof never gave Ken enough information to port it properly to support the entire vopmail userbase. i gave up on this earlier, but to clarify some things to you (and maybe others). a) it does not BREAK anything, it's completely transparent for non-db instalation it's just added functinality for mysql version. You can switch it off while compilation and even if it's turned off, you do not have to use it at all. This means there would be two different featured versions, one for SQL and one NOT-SQL, that's not exactly the result that someone trying to develop a portable, coherent, all features enabled product tries to achieve. It doesn't break the code, but it breaks the product. b) there is full documentation including new api calls, data structures etc. on the website since the day zero. c) after the emails here NOBODY from inter7.com even bothered to check the mentioned website (http://members.elysium.pl/brush/vpopmail/) Please, try to verify your information before spreading lies. Kris Tonino
Re: dbfunctions - it's over
On Mon, 28 May 2001, Krzysztof Dabrowski wrote: *SNIP* c) after the emails here NOBODY from inter7.com even bothered to check the mentioned website (http://members.elysium.pl/brush/vpopmail/) How can you be sure that nobody from inter7.com visted your site? just because you have no http log entrys from *.inter7.com doesn't mean that someone from inter7 couldn't have viewed your site from home or dial-up account Please, try to verify your information before spreading lies. You might take some of your own advice. -- - Sean P. Scanlon perl -e 'print pack(h*, 3707370426c6575646f647e2e65647), \n' -
Re: dbfunctions - it's over
Hi, Can anyone tell me, why there is no answer ( for letters with 'dbfunctions' in Subject ) from inter7.com ? On Fri, 18 May 2001, Krzysztof Dabrowski wrote: Hello.. It's a sad day, but i guess it was ment to be like this We are stoping the dbfunction patch development. There will be no more releases from us. The already finished improved quota support (no re-calc on every delivery with small patch to qmail-pop3d) wont be released too. We have decided to start a similar project on our own. It'll differ from vpopmail in 2 aspects: a) speed - we aim to be nearly as fast as stock qmail but with mass virtual hosting support. b) quota - file system independent fast quota system c) simplicity - no bloat.. At this point of time i can not tell you if it's going to be open project or not - i have to consult our management (we are being paid to program it). But inerested parties can contact me and we can work something out i supose. If somebody wants to maintain the dbfunction patch then feel free to contact me. You will be able to download the last release version together with vpopmial that works with it from my homepage. Thanks for all good words from users of the patch. And to Ken: Sorry, you just don't know how to run an open source project, period. bye, Kris wojciech smokowski [ mailto:[EMAIL PROTECTED]] PGP key: sh# pgpv hkp -a keys.pgp.com/0x2FFD974D [mobile ph. +48502525521] * Powered by /bin/pine
Re: dbfunctions - it's over
It was answered before this posting on the list, when Krzysztof first noticed that the dbfunctions patch in its entirity was not going to be included in the latest vpopmail build. You can check the archives for the exact posting (subject Dbfunctions) but the general of it all was that dbfunctions could not be included in its current state because it breaks non database installations, it lacks documentation and Krzysztof never gave Ken enough information to port it properly to support the entire vopmail userbase. -- Tim - Original Message - From: "Wojciech Smolkowski" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 25, 2001 5:00 PM Subject: Re: dbfunctions - it's over Hi, Can anyone tell me, why there is no answer ( for letters with 'dbfunctions' in Subject ) from inter7.com ? On Fri, 18 May 2001, Krzysztof Dabrowski wrote: Hello.. It's a sad day, but i guess it was ment to be like this We are stoping the dbfunction patch development. There will be no more releases from us. The already finished improved quota support (no re-calc on every delivery with small patch to qmail-pop3d) wont be released too. We have decided to start a similar project on our own. It'll differ from vpopmail in 2 aspects: a) speed - we aim to be nearly as fast as stock qmail but with mass virtual hosting support. b) quota - file system independent fast quota system c) simplicity - no bloat.. At this point of time i can not tell you if it's going to be open project or not - i have to consult our management (we are being paid to program it). But inerested parties can contact me and we can work something out i supose. If somebody wants to maintain the dbfunction patch then feel free to contact me. You will be able to download the last release version together with vpopmial that works with it from my homepage. Thanks for all good words from users of the patch. And to Ken: Sorry, you just don't know how to run an open source project, period. bye, Kris wojciech smokowski [ mailto:[EMAIL PROTECTED]] PGP key: sh# pgpv hkp -a keys.pgp.com/0x2FFD974D [mobile ph. +48502525521] * Powered by /bin/pine
dbfunctions - it's over
Hello.. It's a sad day, but i guess it was ment to be like this We are stoping the dbfunction patch development. There will be no more releases from us. The already finished improved quota support (no re-calc on every delivery with small patch to qmail-pop3d) wont be released too. We have decided to start a similar project on our own. It'll differ from vpopmail in 2 aspects: a) speed - we aim to be nearly as fast as stock qmail but with mass virtual hosting support. b) quota - file system independent fast quota system c) simplicity - no bloat.. At this point of time i can not tell you if it's going to be open project or not - i have to consult our management (we are being paid to program it). But inerested parties can contact me and we can work something out i supose. If somebody wants to maintain the dbfunction patch then feel free to contact me. You will be able to download the last release version together with vpopmial that works with it from my homepage. Thanks for all good words from users of the patch. And to Ken: Sorry, you just don't know how to run an open source project, period. bye, Kris
