On Tue, 2005-05-31 at 17:15 +0000, Aaron Stone wrote: > I've added a page to the wiki with your last three emails. I think we're > at the point where we should hammer out a plan for the implementation. > > http://dbmail.org/dokuwiki/doku.php?id=unique_token > > There's just one piece left to properly refute, and I think that we need > an actual analysis (Geo, the one you provided regarding UIDVALIDITY, > inodes and file offsets would be ideal)
I'm not completely sure what you want here. `` Originally, UW/IMAP could make an optimization of making the UID the binary offset within the mbox file and UIDVALIDITY the inode number. Even if it were never implemented as such because, it can be represented as such, it's going to be the same kind of problem. That means any solution to one problem will work for the other. So, think of it this way: Can you build a file system that distributes across multiple machines, and IF A MACHINE IS DOWN still guarantee that they increase the length of the file at the same time? '' Is this what you were looking for? Are you looking for a rigorous proof that the problems are identical? Or that they are generally unsolvable (without some kind of arbiter)? > http://dbmail.org/dokuwiki/doku.php?id=unique_id_guid > > Because on that page it is currently stated: > > Contrary to earlier thoughts this would be consistent with the RFC. This > is due to the fact that the RFC does not require “increment-only” id’s as > defined in the current DBMail implemenation. The unique_id’s detailed in > the below “RFC Overview” can be guid’s, they must be unique and ascending, > but do not have to be sequential. I don't think I said sequential, but I did say "strictly ascending". Note even in my similar-problem example, I point out that UID numbers could be file offsets in an mbox file- this doesn't suggest that they be sequential, does it? In any event, since the UID numbers will be generated from a token ring, they might as well be sequential. That said, dbmail has it's OWN NEED to maintain a certain amount of referential integrity and I think it's perfectly sane and wise to use GUIDs for that. However. Users need to see UIDs, which means at some level, a map is required. One might as well use UID numbers as that reference, but if tokens are going to be lost frequently, this would mean more overhead. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
