In fact, I would highly recommend that a database is used. I envision a table that has a row for each server in the cluster and a "uuid prefix" or something to the like. Synchronization information might also be stored in this table, such as the IP address of each server as it links up with a row in the database and the timestamp of when it last attached.
Naturally this table will have to be replicated, and so it should not have an auto_increment column, but something else more unique. Hostnames or IP addresses are an obvious answer, if not a good one ;-) I'm not sure what the "non-volatile" storage is needed for in your proposal beyond what I see as a unique prefix for each dbmail in the cluster as it writes to a replicated database server... Aaron On Thu, 12 Jun 2003, Magnus Sundberg wrote: > Hi, > I have a small question, that I don't understand. > What reason is there to not store this data in the database? > > /Magnus > > Jesse Norell wrote: > > Hello, > > > > I'm working on implimenting UUID's into dbmail, and need both > > a place for non-volitale storage, for which I plan on using a > > /etc/dbmail/ directory (with a "nodeid" and "state" file), and > > need an inter-process locking mechanism for which I'm planning on > > using flock() on the state file. Does anyone see any obvious > > red flags going up? Is there a better/more portable/whatever > > way I should be locking the file? > > > > On the issue of unique_id in general, I think our whole problem > > was because we added constraints to guarantee that that field actually > > was unique - that is not necessary, and even arguably wrong. The > > rfc actually says that a client should be able to handle multiple > > messages with the same unique id if it's a duplicate message. This > > consideration may actually come into play if/when there are shared > > folders, if you can move messages from one folder to a shared folder > > so... just don't actually force unique_id to be unique. :) > > > > I plan on making one function to generate uuid's (for unique_id or > > anywhere else, if someone needs them), and then make all the pop3 > > stuff use it everywhere it currently generates a unique_id (in > > multiple functions). > > > > Also, with having an /etc/dbmail/ directory, should that be the > > default location for dbmail.conf? Debian packages already do that, > > and it's cleaner if there are multiple conf/etc. files. > > > > Jesse > > > > > > ---- Original Message ---- > > From: Jesse Norell <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: unique_id discussion/problem > > Sent: Wed, 4 Jun 2003 10:52:58 -0600 > > > > > >>Hello, > >> > >> We're still having issues with unique_id's not always being > >>unique, so - in the past there have been 2 proposed solutions, > >>the first to just use the message_idnr (which already exists, is > >>guaranteed unique and takes no additional db storage space), the > >>second is to use UUID's (universally unique id's). I'd be glad > >>to work on one or the other, but just wanted to head down the > >>right path. > >> > >> Is there any good reason to not use the message_idnr? It looks > >>like the unique_id is sent right to the pop3 client in response to > >>a UIDL command, so it might be handy to still have that present for > >>migration purposes (if someone wanted to load the unique_id's with > >>the same values as their previos mail server had) - what if it > >>uses unique_id if present, and message_idnr if NULL (or simply save > >>message_idnr into that field, checking for duplicates)? > >> > >> UUID's would work, but aside from seeming to be almost superfluous > >>overkill, there are a couple issues to work out, namely the proper > >>place for non-volitale storage of state info (disk file vs. database), > >>and testing on mulitple platforms. I've been referring to the draft at > >>http://lists.research.netsol.com/pipermail/urn-nid/2002-September/000323.html > >>as a reference. I suppose if we didn't use real mac addr's for the > >>node part, but a randomly generated number, there would be no platform > >>compatibility issues (ie. how to lookup the mac addr). The > >>implimentation included in the above url says it works for linux and > >>windows, but I can't test anything but linux myself. > >> > >>Comments / etc.? > >> > >>Jesse > >> > >> > >>-- > >>Jesse Norell > >>jesse (at) kci.net > >> > >> > > > > -- End Original Message -- > > > > > > -- > > Jesse Norell > > jesse (at) kci.net > > > > > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
