5.2.0-git
04/23/2014

[#7989] Request: Support for task relations in SyncML
Summary Request: Support for task relations in SyncML
Queue Nag
Queue Version 2.3.1
Type Enhancement
State Accepted
Priority 2. Medium
Owners
Requester felix.leimbach (at) gmx (dot) net
Created 02/15/2009 (1893 days ago)
Due
Updated 04/17/2010 (1467 days ago)
Assigned
Resolved
Milestone
Patch No

History
04/17/2010 05:39:15 PM felix (dot) leimbach (at) gmx (dot) net Comment #10 Reply to this comment
Do you anticipate that task relations will work out of the box in Horde 4?
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.
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.
04/17/2010 04:14:06 PM Michael Rubinsky Comment #9 Reply to this comment
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)
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.
Do you anticipate that task relations will work out of the box in Horde 4?
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.

04/17/2010 08:55:25 AM felix (dot) leimbach (at) gmx (dot) net Comment #8 Reply to this comment
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?

[Show Quoted Text - 9 lines]
03/17/2010 04:03:08 PM Jan Schneider Comment #7 Reply to this comment
I don't see the RELATED-TO field being removed anywhere.
I don't think we remove it. Off my head I'm pretty sure we only remove 
the UID attribute.
Also, are you interested in such a patch?
I can barely imagine a clean solution with the current SyncML library, 
but we would definitely look at a patch.
03/06/2010 08:11:55 PM felix (dot) leimbach (at) gmx (dot) net Comment #6 Reply to this comment
Thus we don't write or read UID fields during import/export [...]
Interestingly, when I *export* tasks the UID and RELATED-TO *are*
written properly. Only when syncing they are not.
Yes, because they are explicitly removed during synchronization.
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?
03/06/2010 10:03:37 AM Jan Schneider Comment #5 Reply to this comment
Hi Jan,
We can't use the client's UID because many clients don't really
create GUIDs
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.
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.
Thus we don't write or read UID fields during import/export [...]
Interestingly, when I *export* tasks the UID and RELATED-TO *are* 
written properly. Only when syncing they are not.
Yes, because they are explicitly removed during synchronization.
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?
No, it's rather a side-effect of a workaround in Horde for broken 
SyncML clients.
03/06/2010 07:09:09 AM felix (dot) leimbach (at) gmx (dot) net Comment #4 Reply to this comment
Hi Jan,
We can't use the client's UID because many clients don't really create GUIDs
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.
Thus we don't write or read UID fields during import/export [...]
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?
03/01/2010 09:03:08 PM Jan Schneider Comment #3 Reply to this comment
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.
03/01/2010 08:25:11 PM felix (dot) leimbach (at) gmx (dot) net Comment #2 Reply to this comment
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?
02/16/2009 12:38:24 AM Chuck Hagenbuch State ⇒ Accepted
 
02/15/2009 01:15:08 PM felix (dot) leimbach (at) gmx (dot) net Comment #1
State ⇒ New
Patch ⇒ No
Milestone ⇒
Queue ⇒ Nag
Summary ⇒ Request: Support for task relations in SyncML
Type ⇒ Enhancement
Priority ⇒ 2. Medium
Reply to this comment
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