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.

-dg

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.
> 
> poc

_______________________________________________
Evolution-list mailing list
Evolution-list@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-list

Reply via email to