On Mon, 2005-07-25 at 11:30 -0400, Mordechai T. Abzug wrote:
> > Note: "B" however cannot ignore that message. It _MUST_ rewrite
> > it. It's not acceptable for UID 6 to refer to a different message on
> > each host. After that replication, a request for UID 6 must fail.
>
> No; my terminology ("email" vs. "message") may be confusing here. The
> switch from UID 6 to UID 9 for that email is accomplished
> automatically, by DB replication; B has no choice or even knowledge of
> it. After it happens, B has an email with UID 9 and no email with UID
> 6 whether B likes it or not. The message from A to B after A
> reassigns UID from 6 to 9 is going a step farther; it's saying "A
> created UID 9, so B, if the user has read an email with UID 10 or
> later, please go ahead and reassign the UID for email UID 9 to
> something still higher (ie. 11)." Ie. we need to allow for the
> possibility that the scheme will need to be executed multiple times
> for a single email. B can ignore that message if the user hasn't
> downloaded an email with UID 10 or later. If the user has downloaded
> a higher UID from B in the meantime, B needs to go ahead and assign a
> new UID to the email, etc.
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.
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.
> > Also note that this lowers the effective number of messages per
> > mailbox pretty quickly. a UIDVALIDITY change could be needed as
> > quickly as 1.5 million messages on a 64-node dbmail cluster. I have
> > a few mailboxes that large. A two-node dbmail would be sufficient
> > for most, and "only" support about half a billion messages. Someone
> > with a billion messages can suffer if they're using IMAP still...
>
> True. Although you might still mix read-write and read-only servers,
> ie. in a 64-node cluster, you might have two or four masters
> (read-write), and make the rest read-only. The scheme would only need
> to be applied to master servers, so the 32-bit problem would only be
> spread across your master servers, not across all servers.
31-bit. But yes, you're right on this.
> > The good news is that this system is a lot simpler than your
> > mechanism. You can implement it as an IMAP client and DBMAIL needs
> > to know nothing about it (except one point!)
>
> [snip]
>
> I'm not sure I get this, but I'll take your word on it.
* 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)
> > It's less invasive than mine, but I think this will screw up several
> > clients. The question would be "how bad". I'm betting the worst
> > would be Outlook Express....
>
> Frankly, you know a lot more about IMAP and IMAP clients than I do; a
> fair amount of what I know came from reading your old posts. What
> would be the problem with Outlook Express?
Outlook Express "likes to lose messages". It seems largely random
without replicated systems. I don't _know_ Outlook Express because I
don't use it, but I can confirm the messages like "Message no longer
exists on the remote server" cause users endless grief. They seem to be
linked to UID ordering, but they also happen with Microsoft Exchange.
I'm not suggesting it's important to work around these bugs- I'm
suggesting it's important to know what they are.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
