Re: [Evolution-hackers] Hierarchical Tasks [Was: Multiple child-addressbooks under an account]

[Milan Crha <mcrha redhat com>]

On Sun, 2011-01-23 at 16:51 -0500, Adam Tauno Williams wrote:
> You'll also run into consistency issues when using
> GroupDAV/CalDAV/CardDAV and the server tries to be 'helpful' or smart.
> For example if on a CalDAV server I have a todo list of many tasks and
> three of those tasks are linked in some way - the client makes a
> modification to one of those tasks which has a side-effect on the
> status
> of the two other tasks.... the client will remain merrily oblivious to
> that fact that the other objects in the collection have changed.  This
> is just a crappy part of the specs, there isn't any widely supported
> mechanism for the server to notify the client that certain references
> in
> its cache have been invalidated.  The only way the client figures that
> out is if it polls the collection; which can be slow and/or
> computationally expensive.  Polling the entire collection after every
> update would just be brutal - but it is the only way to remain
> consistent. 
> ...

	Hi,
there could be done, as the first step, a hierarchical view of
components based on the Andrew's property, and it can do nothing, as a
starter, with respect of implicit impact on related components, keeping
all this on a user (call it a very simple target calendar system). So
Evolution would use it only for viewing.

Because the RFC doesn't dictate whether client or server should do
implicit impact changes, then the rest can be safely done on the
Evolution side (which avoids update issues you mentioned) by some kind
of plugin, rather than making evolution's UI too complex.

Of course, it might not work with every server, but this kind of issue
is there every time.
	Bye,
	Milan