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
