Re: [Evolution] Can I get an IMAP folder update up in here!

[Patrick O'Callaghan <poc usb ve>]

On Wed, 2008-12-17 at 11:25 -0800, David Graves wrote:
> If Evolution would always update on writes, then It could have a "server
> is always right" policy to incorporate changes made by other clients.

By "writes" I assume you mean "actions which change the user's view of
the mailstore and should therefore trigger a server update". Let's
imagine two clients, A and B, with simultaneous open sessions to the
same mailstore on server S. A new message M arrives in the Inbox:

In A:
1) Message M is \Unseen and triggers a filter rule, which
2) moves M to folder F
3) A synchs to S

In B:
1) User reads message M from the Inbox, then
2) deletes message M (marks for deletion and expunges the folder)
3) B synchs to S

The final state on S will depend on the ordering of events between A and
B, or more strictly on the order of arrival of the various synch updates
at S. Either M will be deleted or it will be filed. The question is:
what is *supposed* to happen? The answer is that this kind of
interaction is not supported, so the result is undefined. The IMAP
designers weren't stupid; they knew this was a can of worms and simply
avoided defining it.

Saying "the server is always right" makes no difference, since the final
result still depends on the ordering of events. This is a basic scenario
in concurrent programming and there is no way to solve it short of
introducing locks on the server (very inefficient) or direct
synchronization between the various clients, something too horrible to
contemplate for a whole bunch of reasons.

The option of an explicit "synch" action could help the smarter user
avoid the problem if used properly, and it would certainly be a
convenience to have, but it still wouldn't be automatic. The best way to
avoid the issue at present is by not allowing it to arise, i.e. by not
having A and B running concurrently.

poc