[Evolution-hackers] Hierarchical Tasks [Was: Multiple child-addressbooks under an account]
- From: Adam Tauno Williams <awilliam opengroupware us>
- To: evolution-hackers gnome org
- Subject: [Evolution-hackers] Hierarchical Tasks [Was: Multiple child-addressbooks under an account]
- Date: Sun, 23 Jan 2011 16:51:21 -0500
Please use Ctrl-L [reply-to-list] rather than Reply-All when replying to
list messages.
On Sun, 2011-01-23 at 15:50 +1000, Andrew McMillan wrote:
> On Sat, 2011-01-22 at 14:23 -0500, Adam Tauno Williams wrote:
> > This really seems like a server-side issue to me. The issue really is
> > there is no way standard way to specify a hierarchy of tasks in either
> > UI or in the representation [VTODO] so I think that would be a
> > special/custom plugin.
> I was under the impression that VTODO did support parent/child/sibling
> relationships.
> Like:
> http://tools.ietf.org/html/rfc5545.html#section-3.8.4.5
It supports relationships, but no specific impact (side-effects) of
relationships.
<QUOTE>
Changes to a calendar component referenced by this property can
have an implicit impact on the related calendar component. For
example, if a group event changes its start or end date or time,
then the related, dependent events will need to have their start
and end dates changed in a corresponding way. Similarly, if a
PARENT calendar component is cancelled or deleted, then there is
an implied impact to the related CHILD calendar components. This
property is intended only to provide information on the
relationship of calendar components. It is up to the target
calendar system to maintain any property implications of this
relationship.
</QUOTE>
The real-world up-shot of that is that no one will do anything with the
attribute described. It would be fantastically useful - the server I
work on supports task hierarchies, but to make use of them you need to
write 'native' code and your own UI, for VTODO's you are best of just
hiding that aspect of the data model (and I've never seen a client that
supported it in any capacity).
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.
So your proposed feature of the completion of child tasks bumping the
percent complete of the parent task would be frustrating for the user
because the user would not see the percentage of completion of the
parent task change. And what if they then open the parent task and
manually set the percentage complete? You now have a conflicting
update.
Beyond that there is the issue that if the parent task has four
children, and three are complete - so the percent complete is 75% - and
the user adds a fifth child task does the percent complete now decrease
to 60%? What if each of the child tasks is not a proportional section
of the parent task? Do you let the user specify each sub-total of work?
There certainly is no standard attribute for that so you are down to
using an X- attribute that risks getting discarded by badly behaving
servers and clients. And of course that would require a customized UI
to be of any value to the user.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]