6.0.0-git
2019-03-23

[#6658] Allow attribute deletion between SyncML partners
Summary Allow attribute deletion between SyncML partners
Queue Synchronization
Type Enhancement
State Resolved
Priority 2. Medium
Owners jan (at) horde (dot) org
Requester wrobel (at) horde (dot) org
Created 2008-04-28 (3981 days ago)
Due
Updated 2010-07-08 (3180 days ago)
Assigned 2008-05-01 (3978 days ago)
Resolved 2010-07-08 (3180 days ago)
Milestone
Patch Yes

History
2010-07-08 15:41:54 Jan Schneider State ⇒ Resolved
 
2010-07-08 13:53:42 lst_hoe02 (at) kwsoft (dot) de Comment #45 Reply to this comment
Finally got the time for a short test.It works fine to not export 
attributes not supported by the client (tested with Thunderbird / 
Funambol SyncML and PHOTO attribut).
So for now i think we should close this bug and handle any further 
findings in a new bug-ticket if any arises.
2010-06-15 15:28:52 Jan Schneider Comment #44 Reply to this comment
Ping?
2010-04-08 13:53:15 lst_hoe02 (at) kwsoft (dot) de Comment #42 Reply to this comment
HTTP Link???
2010-04-08 12:06:20 Jan Schneider Comment #41 Reply to this comment
From CVS.
2010-04-08 09:20:01 lst_hoe02 (at) kwsoft (dot) de Comment #40 Reply to this comment
So how do i get the correct files for Horde 3.3.6 and Turba 2.3.3 ??
2010-04-08 08:56:40 Jan Schneider Comment #39 Reply to this comment
Yes, you are mixing Git master with CVS FRAMEWORK_3. The links from 
the commit message are for the Git version.
2010-04-08 08:49:08 lst_hoe02 (at) kwsoft (dot) de Comment #38 Reply to this comment
sixth link in your post from 12.01.2010, chossing the right hand 
version from the diff page (Version fd75....) in the 10th line i get:

"class Turba_Api extends Horde_Registry_Api "

Or have i done something wrong???

2010-04-07 21:31:15 Jan Schneider Comment #37 Reply to this comment
Apr  7 15:22:02 h1397077 apache2: PHP Fatal error:  Class 
'Horde_Registry_Api' not found in /var/www/horde/turba/lib/api.php 
on line 10
There is no such line in api.php.
2010-04-07 13:26:57 lst_hoe02 (at) kwsoft (dot) de Comment #36 Reply to this comment
Seems to need more changes around than the files listed. I got this 
one when try to log in with the patched turba/lib/api.php file

Apr  7 15:22:02 h1397077 apache2: PHP Fatal error:  Class 
'Horde_Registry_Api' not found in /var/www/horde/turba/lib/api.php on 
line 10

Is it possible that additionally a not-yet-released Horde 3.3.7 
api.php is needed??
2010-04-07 12:00:37 lst_hoe02 (at) kwsoft (dot) de Comment #35 Reply to this comment
Will try this week with TB3 and 1.0b3 Funambol...
2010-04-05 13:14:45 Jan Schneider Comment #34 Reply to this comment
I will try to test the patches as soon as possible.
Any news?
2010-01-13 13:59:01 Jan Schneider Comment #33 Reply to this comment
Yes, that should be sufficient. I'm not sure why they haven't been 
linked to the ticket, but you should be able to figure that out.
2010-01-13 10:54:10 lst_hoe02 (at) kwsoft (dot) de Comment #32 Reply to this comment
I will try to test the patches as soon as possible. Will it be enough 
to apply the latest CVS chages from 12.01.2010 to Horde 3.3.6 and Turba?
2009-12-30 16:13:37 Jan Schneider Comment #29 Reply to this comment

[Show Quoted Text - 15 lines]
This has been implemented, at least for Turba, where it's more 
necessary than for other applications. The patches could be used by 
someone to implement similar solutions for Nag and Kronolith.
2009-12-17 12:11:10 Jan Schneider Milestone ⇒
 
2009-10-01 12:57:15 Jan Schneider Comment #25 Reply to this comment
SyncML_Backend::retrieveEntry() should take a new optional parameter 
with the list of attributes to expect. This method is called in 
SyncML_Sync::createSyncOutput() where you have access to that 
information from the DevInf.

The pass this list further along, e.g. to _kronolith_export() in 
lib/api.php, Kronolith_Event::toICalendar() and so on.
2009-10-01 12:38:17 lst_hoe02 (at) kwsoft (dot) de Comment #24 Reply to this comment
I will try if i can get something working, but i doubt that i have 
understand enough from the Horde code to do this soon :-(

It would be nice if you can give me some hints where i would have to 
dig around to get it right.




2009-10-01 12:05:48 Jan Schneider Comment #23 Reply to this comment
For telling contacts/export which keys we want : I have seen no
possibilty to do so without changing a lot of code in
Turba/Kronolith/Nag. As the drop of attributes is only necessary for
SyncML, my intention was to let it there. Maybe the clean way (extend
the API) should be planed for Horde 4 ??
I would rather accept a Horde-4-only solution than using a short-term 
hack that would have to be re-done for Horde 4 anyway. Implementing 
this correctly now will save us work in the future.
2009-10-01 12:02:52 CVS Commit Comment #22 Reply to this comment
Changes have been made in CVS for this ticket:

MFH: Update deleted attributes during synchronization 
(lst_hoe02@kwsoft.de, Request #6658).
http://cvs.horde.org/diff.php/turba/lib/Driver.php?rt=horde&r1=1.57.2.89&r2=1.57.2.90&ty=u
2009-10-01 11:48:44 lst_hoe02 (at) kwsoft (dot) de Comment #20 Reply to this comment
The array_key_exists() calls seams necessary because eg. for 
department/company i get no attributes if the isset() call is used, so 
i guess the attributes are not initialized with empty string. If you 
suspect worse performance : According to PHP bug-tracker there was a 
bug in PHP 5.1.x which lead to array_key_exists() performing much 
worse than isset(), but this should be fixed since around 2006.



For telling contacts/export which keys we want : I have seen no 
possibilty to do so without changing a lot of code in 
Turba/Kronolith/Nag. As the drop of attributes is only necessary for 
SyncML, my intention was to let it there. Maybe the clean way (extend 
the API) should be planed for Horde 4 ??


2009-10-01 11:05:02 Jan Schneider Comment #19 Reply to this comment
This patch is to remove potential big-sized attributes before sending
if the client don't support this attribute anyway. For now i have
included the attributes PHOTO,LOGO,SOUND,KEY,NOTE for x-vcard and
ATTACH for calendar Types.
It's probably more work, but we should instead tell contacts/export 
which keys we want. This is much safer than filtering the attributes 
out of the generated vCard later. This has to be implemented with 
backward compatibility in mind, because it requires changes in both 
Turba and Horde.
2009-10-01 11:00:41 Jan Schneider Comment #18 Reply to this comment
First Patch against Horde 3.3.5 /turba/lib/Driver.php :
It does alter Turba to use all supplied empty attributes to clear the
matching Adressbook fields and to always sent all (even empty ones)
attributes available as vCard to clear attributes on the client.
Are the array_key_exists() calls really necessary? Are those 
attributes really null (as opposed to empty strings), if not set?
2009-09-30 12:25:41 lst_hoe02 (at) kwsoft (dot) de Comment #17
New Attachment: CTCaps-sending.zip Download
Reply to this comment
This patch is to remove potential big-sized attributes before sending 
if the client don't support this attribute anyway. For now i have 
included the attributes PHOTO,LOGO,SOUND,KEY,NOTE for x-vcard and 
ATTACH for calendar Types.



Some things to check :



- The preg_replace is stolen from the UID remove some lines above. I 
doubt it is the most effective solution for this case but my preg 
knowledge is very limited.



- Not sure if we should check for multiple occurence of the Attributes 
in question.



- Only tested with Mozilla-Funambol Plugin as it is the only CTCaps 
sending client we have today.




2009-09-29 11:06:32 lst_hoe02 (at) kwsoft (dot) de Comment #16
New Attachment: use-all-attributes-turba.zip Download
Reply to this comment
First Patch against Horde 3.3.5 /turba/lib/Driver.php :

It does alter Turba to use all supplied empty attributes to clear the 
matching Adressbook fields and to always sent all (even empty ones) 
attributes available as vCard to clear attributes on the client.
2009-09-29 09:59:20 Jan Schneider State ⇒ Feedback
 
2009-09-29 09:59:04 Jan Schneider Comment #15 Reply to this comment
I like to split the patches and supply in pieces after
finishing/testing if you don't mind so the changes would hopefully be
more understandable??
Sounds great.
2009-09-28 15:50:25 lst_hoe02 (at) kwsoft (dot) de Comment #14 Reply to this comment
I like to split the patches and supply in pieces after 
finishing/testing if you don't mind so the changes would hopefully be 
more understandable??

Splitting would be like this :

- Change Turba to supply all know attributes in vCard (sending)

- Change Turba to respect CTCaps for sending

- Change Turba to check CTCaps for receiving



Same for Kronolith and maybe Nag...
2009-09-28 10:21:58 Jan Schneider Comment #13 Reply to this comment
Would this be an acceptable approach?
Sounds good.
2009-09-28 10:05:02 lst_hoe02 (at) kwsoft (dot) de Comment #12 Reply to this comment
When receiving set all attributes empty for which we get empty 
attributes in the data. This is already done for Turba not sure about 
Kronolith. As addition check if we get capabilities from the client 
and use them to set attributes empty which the client supports but 
have not delivered (this is the second part of the patch).



When sending provide all attributes we know in the data, even empty 
ones. Additionally check if we have client capabilities to avoid 
sending useless attributes which may get big in size like photo,notes 
etc. This is not yet done for Turba/Kronolith.



Would this be an acceptable approach?



From my findings it seams the "CTCaps" are not well supported by most 
clients and are stated as "should" not "must" in the SyncML Standard.


2009-09-28 09:46:47 Jan Schneider Comment #11 Reply to this comment
Okay, but is it acceptable to first use the approach send all known
attributes / set received emtpy ones empty and additionally use the
capabilities if the client provides them? We have only clients which
use this approach and only one of them send capabilities at all, but
i'm not sure if we detect them right.
Sorry, I don't follow what exactly you want to do under which conditions.
BTW : Does Horde *send* capabilities to the client? I have not found
anything in the /tmp/sync data.
No, not yet.
2009-09-28 08:44:55 lst_hoe02 (at) kwsoft (dot) de Comment #10 Reply to this comment
Okay, but is it acceptable to first use the approach send all known 
attributes / set received emtpy ones empty and additionally use the 
capabilities if the client provides them? We have only clients which 
use this approach and only one of them send capabilities at all, but 
i'm not sure if we detect them right.

BTW : Does Horde *send* capabilities to the client? I have not found 
anything in the /tmp/sync data.
2009-09-25 12:16:44 Jan Schneider Comment #9
Taken from Karsten Fourmont
Priority ⇒ 2. Medium
Milestone ⇒ 3.3.6
Reply to this comment
Reading the original message that is linked in the first comment, it 
is not sufficient to rely on the client to send all known attributes. 
So we still need to create empty values for attributes that are listed 
in the capabilities but not in the actual data.
2009-09-24 15:53:06 lst_hoe02 (at) kwsoft (dot) de Comment #8 Reply to this comment
Any comment??

Is it the way to go simply sent all supported attributes as 
vCard,VCalendar and use all empty ones sent by the client to delete 
attributes. This seams to be the "consent" of the limited number of 
SyncML applications i have seen.
2009-09-10 21:27:27 lst_hoe02 (at) kwsoft (dot) de Comment #7 Reply to this comment
Re-thinking the whole story, why not just do as others and simply 
provide all known attributes on sending and use all provided when 
receiving? This way deleting of attributes would work and we don't 
have to bother if the client send its CAPs or not (Funambol does not 
for example). We could use provided capabilities to surpress potential 
large data like "photo" if the client does not support it anyway.

Any comments/thoughts if this is acceptable??
2009-09-10 14:15:46 lst_hoe02 (at) kwsoft (dot) de Comment #6
New Attachment: patch-2.zip Download
Reply to this comment
If have altered the patches to apply to Horde 3.3.4 / Turba 2.3.1 and 
as far as i can test it works o.k.



- The "_CTCap" seams to be renamed to "CTCaps" as far as i can see??



- Most clients seam to send their whole set of attributes anyway so 
clearing works with only the turba driver patch.



- Despite the server (Horde) does not set empty attributes on send 
some clients do a replace instead of modify so the delete works from 
server -> client in some cases.




2009-03-25 16:46:30 Jan Schneider Comment #5 Reply to this comment
Testing always helps. Check if the patch still applies for you and 
works as expected.
2009-03-25 14:53:52 Lst_hoe02 (at) kwsoft (dot) de Comment #4 Reply to this comment
Is there any progress on this one?? It is urgently needed for us to be 
able to clear attributes especially for situations like described in 
bug #7470 for Kronolith (ALARM reminder get not cleared but synced to 
all clients over and over again).

Let me know if i can help out with testing etc.



Many Thanks



Andreas


2009-01-10 13:12:01 Jan Schneider Deleted Original Message
 
2008-05-07 13:21:58 Gunnar Wrobel Comment #3
New Attachment: HK-GW-SyncML_delete_attributes[2].patch Download
Reply to this comment
Updated patch to current CVS HEAD.
2008-05-02 17:53:56 Jan Schneider Patch ⇒ Yes
 
2008-05-01 21:01:57 Chuck Hagenbuch State ⇒ Assigned
 
2008-04-28 08:07:07 Gunnar Wrobel Assigned to Jan Schneider
Assigned to Karsten Fourmont
 
2008-04-28 08:06:51 Gunnar Wrobel Comment #2
New Attachment: HK-GW-SyncML_delete_attributes[1].patch Download
Reply to this comment
This additional turba patch fixes empty attribute values for turba and 
ensures that empty vcard attributes are interpreted as "delete this 
attribute".
2008-04-28 08:06:15 Gunnar Wrobel Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ Allow attribute deletion between SyncML partners
Queue ⇒ Synchronization
Milestone ⇒
Patch ⇒ No
New Attachment: HK-GW-SyncML_delete_attributes.patch
Reply to this comment
As discussed on the SyncML mailing list, deletion of attributes is 
left somewhat undefined for SyncML.



http://lists.horde.org/archives/sync/Week-of-Mon-20080331/001771.html



The attached patch fixes this problem at least for clients that send 
their capabilities along.


Saved Queries