Timo Sirainen wrote:
I agree that it would be nice to offer this capability for IMAP clients, but I don't see a way to do this in any reasonable way. If the client wants a continuous replication for all mailboxes the resulting protocol will barely even look like IMAP anymore. And trying to merge all the initial sync + continuous replication + IMAP functionality to the same process would be quite ugly.
My first thought was an IMAP command which would read a folder's "log files" from a certain point in time and continue to stream all changes down the connection from that point onwards. Normal IMAP commands could then be used to fetch the details of the changes
However, that's not compatible with the idea of a single iteration sync (takes at least two round trips)
A command to grab the log files and relevant data would seem to work, but doesn't really offer any benefits to be done down the same socket (other than perhaps to be able to use normal imap auth to limit the mailboxes which are accessible?). Actually being able to limit the accessible mailboxes suddenly seems quite important... We can't necessarily trust the remote location admin so we do need some way to restrict their access - perhaps a normal login is required (this presumably means the need for multiple connections to sync multiple mailboxes though? This may not scale for large numbers of mailboxes?)
My thought is still that it's hard to separate the needs of a typical IMAP client from the requirements to sync two servers - there much be some overlap here that we can exploit? Ideally we also want this stuff to be documented in a way that would allow other IMAP servers to participate in sync (although there is nearly zero chance of it ever happening I guess...)
Given how little stuff like QRESYNC is apparently implemented in the real world I guess it's no big problem to "improve" the spec further if this helps (as long as we document where we deviate)
Hmm
Ed W