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

I understand. Anytime two clients are accessing the same folder there
will be all sorts of wierdness. 

My point is this: 

More frequent updates, even immediate updates of status chagnes
(reads/deletes) means less wierdness. 

I can't imagine why we would want evolution to wait hours and hours to
mark something read. Eventually we're going to do a folder update, and
when we do there might be wierdness. I vote to do it immediately rather
than wait as long as possible. It doesn't "solve" the problem, but it
does minimize it and beyond traffic, I see no downside.

If we never wait to update the server, then we never have to worry "is
this change newer than mine."

However you cut it, waiting to update just makes things worse. That's
how I see it.


On Wed, 2008-12-17 at 21:02 -0430, Patrick O'Callaghan wrote:
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]