5.3.0-git
2014-10-22

[#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 2009-02-15 (2075 days ago)
Due
Updated 2010-04-17 (1649 days ago)
Assigned
Resolved
Milestone
Patch No

History
2010-04-17 17:39:15 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.
2010-04-17 16:14:06 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.

2010-04-17 08:55:25 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]
2010-03-17 16:03:08 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.
2010-03-06 20:11:55 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?
2010-03-06 10:03:37 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.
2010-03-06 07:09:09 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?
2010-03-01 21:03:08 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.
2010-03-01 20:25:11 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?
2009-02-16 00:38:24 Chuck Hagenbuch State ⇒ Accepted
 
2009-02-15 13:15:08 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