In reviewing the rfc, there is *no* "increment-only" requiment in the rfc as defined in the current dbmail implemenation.
(detailed in earlier messages from this thread.) There are unique_id's detailed in the past messages... -and- message-ids which are as you said increment-only or sequential per mailbox. However they can change per session, meaning they are not static id's. The rfc basically explains that they can change each request/session, meaning they are really just the current sequence in the mailbox. Because of this we were discussing just generating the message-id's on client request from the imap server and removing them from the schema. They would essentially be just the sequence number of a message within its mailbox generated on the fly with the client request. If the sequence changes during mailstore syncing, they are reordered on the next request. This seems completely consistant with the rfc. It is a new discussion of course and different from the current setup with dbmail, but solves the problem of colliding message-id across multiple-servers and is compliant with rfc. As you said... "prove me wrong." ;) But I'm pretty confident a thorough review of the messages in this thread and the rfc would put us all on the same page. Its not that dbmail implementation is wrong.. its just that the rfc leaves a lot of breathing room from where the current implementation is. That room can be used to correct these issues. - Kevin > On Thu, Sep 02, 2004 at 10:32:39AM -0700, Kevin Baker > wrote: >> >> >> A prev message in thread discussed this solution in >> >> project. Apparently it works great. >> > >> > Are you referring to Simon Cocking's message? I don't >> > think he was >> > referring to IMAP. >> > >> >> Right that was the message I was referring to. He was >> talking about message routing through his system. While >> it >> is not IMAP it touches on all the same issues and seems >> to >> work well. > > I'm sure the unique id problem can be solved in a multiple > master setup, > but I'm not sure about the increment-only IMAP requirement > without some > kind of global locking scheme. I look forward to being > proven wrong, > though. > > xn > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
