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 _______________________________________________ Evolution-list mailing list Evolution-list@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-list
