I was thinking about this some more.
>From RFC2060, if the server sent:
* EXISTS 8
and then later sent:
* EXISTS 11
then the client knows that there is a UID 9, UID 10, and UID 11. But it
doesn't know which is which. If the UID mapping field in the DB is null,
we can block the client if they do a:
wjwe UID FETCH 9:11 ALL
because while we can tell those UIDs are valid- they're just not
attached/assigned to any message.
Meanwhile, by blocking the client on "UID xyz" operations instead of on
the APPEND operations, if the client is just dropping a message in their
Sent Items folder, they won't see any unnatural delays.
Likewise, if the client doesn't _use_ UID numbers, they won't see any
delays.
SMTP servers/other-injection-methods should still block.
It also would be a good idea to know how various clients react when UID
commands fail and no UIDVALIDITY message is presented (i.e. with a
server lacking UIDs) - do they fail over onto using message sequence
numbers?
Another thought was implementing a replacement for UID. The cyrus people
are interested in HA systems as well, they might support something
clever and unobtrusive.
I recommend "XID" which introduces exactly one new command and no new
capabilities. It also adds an XID message attribute.
an XID is a pair of tokens separated by a hyphen ("-"). The first part
is a "namespace" - each server that can introduce messages in a cluster
has their own. The second is a strictly-increasing number.
XHXID (or if ever standardized "HXID") given a "known state". This state
consists of all known namespaces and the highest sequence number that
the client is aware of:
x XHXID foo-1234 bar-5678
* XHXID foo-1235
* XHXID bar-5679
* XHXID bar-5678
* XHXID baz-1
x XHXID OK
Note that the client never knew about host "baz", but does now!
XHXID can also be used "instead of UID" anywhere and everywhere UID is
supported in rfc2060. The only exception is that XID strings don't
support message ranges. Thus an XID supporting client is recommended to
first say:
y SEARCH 1:* XID
If the server responds with message identifiers and XID strings, then
they can "save the current state" and use XID numbers in the future.
A server that at one point supported XIDs might in the future stop
supporting them. Client should do the same thing that they would do if
UIDVALIDITY changed and re-synchronize.
Anyone feel like fleshing this out and trying to convince clients to
help extend IMAP into a HA/clustered environment (not just a load-
balanced one)?
I'm certain Outlook [Lookout!] Express would be the only tricky client
to court, but in many HA IMAP environments, Outlook Express is obsolete
anyway, so it may just make enough sense to get Thunderbird and
Evolution and friends to jump on board.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
