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
