On Mon, 2005-07-25 at 19:47 -0400, Mordechai T. Abzug wrote: > On Mon, Jul 25, 2005 at 12:36:43PM -0400, Geo Carncross wrote: > > > It is. That's okay- the idea is that "B" will simulate a delete of > > uid "6" as part of the replication, otherwise a client connecting to > > "B" will see two copies of one message, and connecting to "A" it > > will see two copies of a different message. > > At least the way I was envisioning it, it's not so much as a "delete" > as an "update" (in SQL terms.) Ie. in pseudocode, something like > "update email_table set uid=9 where uid=6 and mailbox_id=whatever and > user=whatever". The key is that "B" shouldn't have to consciously do > it, at the application layer; after "A" updates, the DB layer should > propagate the change to "B"'s DB via replication.
Right. but... > > Think about how you need to replicate changing flags (deleting, > > replied, etc)- those are tied to the UID as far as the client is > > concerned. We need to simulate the delete and copy any flag-changes > > or at the very least, the human being using the mailbox will be > > confused. > > Good point. > > I don't know dbmail internals, but I'm imagining flags are stored in a > table somewhere, keyed either on UID or on some other attribute of an > email (ie. an internal global unique ID, or the like.) If they're > keyed on UID, then it is the responsibility of the server that changed > the email UID (ie. server "A") to also maintain referential integrity > of the flag table by changing the UID in the flag table. If the flags > are stored with a different key, or even better, if they're stored in > the same table as the email, then the changing of the UID has no > impact on the flags, ie. the flags are associated with the email > independently of any changes to UID, and no additional work needs to > be done. If a flag changes on UID 9 on host A and host B at nearly the same time (between replications) which flag change wins? What if they're not incompatible (one marking +FOOBaz and the other marking \Answered ?) See, the SQL server _can't tell_ what kinds of changes are mergeable. Any UPDATE or DELETE operation _MUST_ be logged separately. INSERTS could be blindly copied, but when doing replication for real, logs are simply easier. [[ fortunately, dbmail puts all of its sql operations through a single point. adding logging here is trivial ]] For testing, we can simulate this nonsense with an IMAP client that does replication, but during real development, dbmail still has to be painfully aware of the replication process... > > * Write an IMAP client (steal one) > > * have it select each mailbox in turn, and for each message that has a > > UID on one but not the other: > > append to both- > > doing extra appends on one machine until UIDs match > > delete the originals and extras > > secret-expunge > > > > The "replication client" will need to know about "deleted messages" - > > thus DBMail will have to log client-expunges so that they can be > > replicated. > > > > If flags have changed, copy flags (using logs as well) > > Is the replication client itself in charge of replication, or is this > assuming a DB-layer replication and the "replication client" is only > responsible for UID sanitizing? In reality, the IMAP server can avoid the overhead of sending the message back and forth by simply modifying the various db attributes, but to find out exactly how your scheme would fare against other clients, I'd suggest this less invasive approach. Since the algorithm isn't strictly RFC2060 conforming (and clients aren't strictly RFC2060 conforming) it's important to find out exactly how clients will deal with UIDs moving around on them all the time. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
