Yea you're right, I'm managing tasks on the iPhone only through the 
SyncML TODO+Cal application and that will still require SyncML.
So I'll come up with a patch for this request when I find the time.

ActiveSync and SyncML are completely separate protocols. Not all 
devices support ActiveSync (most notable blackberry devices) and not 
all devices support SyncML, so we do still need to support both.
As far as ActiveSync goes, no.  There is no support for child tasks in 
the AS protocol. There are also quite a few clients (iPhone included) 
that have NO support for tasks whatsoever.

Haven't found the time to work on this yet, but I'm wondering whether 
it is useful at all, since from what I hear horde 4 will have a new 
Active Sync component:

"Horde 4 will also sport more mobile device features with an 
ActiveSync server component entering the main development tree in time 
for the final release." (from 
http://www.techworld.com.au/article/342104/horde_open_source_groupware_preps_version_4_release)

Do you anticipate that task relations will work out of the box in Horde 4?

I don't think we remove it. Off my head I'm pretty sure we only remove 
the UID attribute.
I can barely imagine a clean solution with the current SyncML library, 
but we would definitely look at a patch.

OK, so this is work-around for broken clients. I believe the iPhone 
Synthesis client does not belong in that category.
I want to create a patch to selectively disable that work-around for 
known-good clients. I'm currently digging into the lib/SyncML/ folder 
and my only uncertainty is:
I don't see the RELATED-TO field being removed anywhere.
Any clue as to why they are missing?

Also, are you interested in such a patch?

I'm talking about objects created by the device. Some devices assign 
them UIDs that are simply incrementing integers. These are of course 
not globally unique IDs so we can't rely on them.
Yes, because they are explicitly removed during synchronization.
No, it's rather a side-effect of a workaround in Horde for broken 
SyncML clients.

Hi Jan,
I'm not sure how you mean this. As far as I understand the server 
needs to assign and send the UID (not GUID) and the client just uses 
them.
Interestingly, when I *export* tasks the UID and RELATED-TO *are* 
written properly. Only when syncing they are not.

I found this analysis of the problem by the synthesis developers helpful:
http://forum.synthesis.ch/showpost.php?p=3204&postcount=7

So this seems like a horde bug to me, or am I missing something?

We can't use the client's UID because many clients don't really create 
GUIDs, but simply some incrementing number for this field. Thus we 
don't write or read UID fields during import/export, because they 
won't be used anyway, and wouldn't match the UIDs we use in the SyncML 
protocol.

I've made an interesting observation: When I export my task list in 
the vTodo format the UID and RELATED-TO attributes are set correctly.
But when I sync via a SyncML client and sniff the network traffic I 
see that the UID and RELATED-TO are missing as described in the 
synthesis forum post linked below.

Any clues?

Nag supports task-relations, i.e. a task can have child tasks. 
However, when syncing tasks with SynML those relations are not 
preserved.

That is because horde does not fill the UID and RELATED-TO fields properly.

The effect is, that nested tasks loose their relations when synced.



A Synthesis developer has tracked down and described the issue in a 
forum post:

http://forum.synthesis.ch/showthread.php?p=3204#post3204