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
