<snip: 24bit explination> > Unfortunately, 24 bits will only hold about 6 months worth > of seconds. > > Using UNIX time only gives us until 2038 before we're > screwed; and that's > if there's one message per second. Using a time window > could help with > this, which is what I think Paul might have mentioned in a > previous email: > > next_uid = (curret_time - mailbox_time) > > By subtracting the mailbox's creation time from the > current time, we > effectively restart the sequence, and, in a weird way, we > give each > mailbox about 50 years to live from the time of the > mailbox's creation.
So I've been thinking more about this. Sounds like a great idea. Would the mailbox_time be system-wide or would it be a set server setting. Either way I think 50 years is a good comprimize. Then we can put in for an update to a 64 bit UUID. That should be cleared w/in 50 years ;) Kevin > > If we do this: > > next_uid = (curret_time - mailbox_time) (24 bits) . server > id (7 bits) > Then the mailbox only has 6 months, with a cluster of 128 > machines. > > next_uid = (current_time - mailbox_time) (27 bits) . > server id (4 bits) > Then the mailbox has 5 years to live, with a cluster of 16 > machines. > > next_uid = (current_time - mailbox_time) (29 bits) . > server id (2 bits) > Then the mailbox has 17 years to live, with a cluster of 4 > machines. > > --- > > Sadly, it's looking like 32 bits is just too small to > combine time with > anything else. We could go to a keyserver architecture, > where there's one > machine that has the task of doling out the next keys, > which means we > would be bound not by time but by the number of messages, > but it also > means that we'd lose significant clustering flexibility. > > *** > > Why isn't the a spec for 64 bit IMAP ids yet?! Should we > write one? > > Aaron > > > On Thu, May 26, 2005, ""Kevin Baker"" > <[EMAIL PROTECTED]> said: > >>> Geo Carncross wrote: >>>> On Thu, 2005-05-26 at 13:49 +0200, Paul J Stevens >>>> wrote: >>>> >>>>>Ok, let me recapitulate: >>>>> >>>>>- we want to replace all auto-incremented fields with >>>>> bigint fields to >>>>>hold uuids in order to accomodate N-clustered >>>>> databases. >> >> So the problem seems to be generating a sequential 32bit >> char based on time and server id. >> >> I'll have to do some reading on 32bit chars... to get my >> head around this... >> >> >> Kevin >> >> <snip: comments that seem to go over stuff from last >> years >> thread> >> >> _______________________________________________ >> Dbmail-dev mailing list >> Dbmail-dev@dbmail.org >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev >> > > -- > > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
