I totally understand about the RFC. Where is it located I'd love to read through it.
So crazy ideas... ;) Here's one that might help in some cases. We would mostly be concerned with colliding messageids on a master-master enviroment, with two machines. Would it be possible to force one machine to even numbers and the other to odd? I'm sure it has lots of holes, but something to throw out there. It would likely end up skipping some numbers, but would be pretty much sequential and avoid collisions. Kevin > ""Kevin Baker"" <[EMAIL PROTECTED]> said: > >> I was wondering where things were on replacing auto >> incrementing message id's with a GUID [unique_id]. >> >> The response I got on the other dbmail list was that >> IMAP >> requires a sequential message id. Is this RFC or an >> actual >> requirement? I would think that this would be a major >> problem for scalability with any email system bound to >> this. We certainly don't use sequential ID's in any of >> our >> apps any more for that reason. > > Yep, that's exactly the problem. The IMAP RFC requires > that the sequence > number be unique and always incrementing. With respect to > RFC and "actual > requirement" the RFC language used in this case is MUST, I > believe. That > makes it a firm requirement. Even if it were a SHOULD, if > all other > implementations have this behaviour, and client programs > expect it, then > it becomes a de facto MUST and we'd have to abide by it > for > interoperability's sake. > >> Anyway, I have been reading through the archives and >> found a >> thread from a year ago that seems to touch on it. >> >> [Dbmail] MySQL Load Balancing & Failover >> http://tinyurl.com/3m6mf >> >> The advantage of course would be non-colliding message >> id's in a server cluster with mysql multi-master >> replication. >> >> I guess I'm curious how difficult it would be to patch >> the >> system for it. I haven't spent much time with the code, >> but couldn't the unique_id be used instead of the >> existing >> ID. > > If we can find another way to comply with the RFC besides > automatic > database sequence numbers, we will definitely go for it. > Any ideas, > however crazy, are welcome... although the really crazy > ones will probably > just be used to help come up with simple straightforward > plans ;-) > > Aaron > > -- > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
