I'm not here to stop anyone from trying anything; the question was pretty much a repeat of discussions that have been had two or three times already. As I've said before, I'm just a frequent contributor to this mailing list, and in this case the contribution was to say 'yes, this has been discussed, but no, it isn't likely to happen anytime soon.'
'Threatening' a fork isn't a bad thing in any way, IMHO. I'd LOVE to use a version of DBMail that has robust clustering support. But I also believe that it's the last thing DBMail should be working towards now. There are a lot of other projects happening that will have much more value to many more people than clustering. Think of Linux and SMP or NUMA. You don't need it to have a great system that lots of people use, but having it is very useful for those that do need it. On the other hand, having *only* SMP and NUMA and everything else half way would be useless to everyone. Again, let me reiterate clearly: I am not stopping anyone from anything. I am a frequent contributor to the mailing list looking to give brief and succint information about a topic that has been discussed at *very* long length *several* times. Reading some of my other posts, you will find that I also try to keep a finger on the pulse of the DBMail community. As this post explains, clustering is an important and desired feature, but is not nearly at the top of most people's active wish lists at this time. Aaron On Mon, 7 Apr 2003, Angel Todorov wrote: > Hello Aaron, > > As Lou said, I don't think it's appropriate to stop some kind of a > developing process only because it requires a lot of changes in the main > DBMail design (correct me if I'm wrong but as far as I've read the previous > mail archives, that was the main issue that's been discussed). Since there > are seemingly many people who wish to contribute to the dbmail project, > including me, I see it more as a matter of organization.On the other hand, I > don't think *any* kind of genetic algorithms or any other EA techniques are > necessary, what we need is just an algorithm to handle uniqueness & so. > Moreover, don't forget that if this finally succeeds, it will not only make > dbmail a very robust mail storage solution for a lot of enterprise companies > , but also increase its popularity among developers. > > Angel > > > On Sat, 5 Apr 2003 07:20:53 -0800 (PST) > Aaron Stone <[EMAIL PROTECTED]> wrote: > > > This has been discussed at length on the mailing list; see the archives > > for pertinent arguments on both sides. In a nutshell: don't do it. > > > > Aaron > > > > > > On Sat, 5 Apr 2003, Michael Kummer wrote: > > > > > hi again! > > > > > because I can't find any hint in the mysql docs about using master-master > > > replication I'd be very happy if you could explain it how you managed it. > > > > > Mit freundlichen Gr__en / yours sincerly > > > > > > > Michael Kummer (GF) > > > > > -- > > > [M]ichael.[K]ummer.[I]ncorporated > > > Lieferinger-Hauptstrasse 47 - A 5020 Salzburg > > > Tel. +43 662 430978 0 > > > Fax +43 662 430978 30 > > > Mobil +43 664 3937630 > > > E-Mail: [EMAIL PROTECTED] > > > Web: www.mki.bz > > > > > _______________________________________________ > > > Dbmail mailing list > > > [email protected] > > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > > _______________________________________________ > > Dbmail mailing list > > [email protected] > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > -- > actions speak a lot louder than words where it's concerned. > > Jordan K. Hubbard >
