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.

Ping?

http://www.horde.org/source/cvs.php
http://git.horde.org/?rt=horde

HTTP Link???

From CVS.

So how do i get the correct files for Horde 3.3.6 and Turba 2.3.3 ??

Yes, you are mixing Git master with CVS FRAMEWORK_3. The links from 
the commit message are for the Git version.

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???

There is no such line in api.php.

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??

Will try this week with TB3 and 1.0b3 Funambol...

Any news?

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.

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?

Changes have been made in Git for this ticket:

MFB: [jan] Only synchronize those fields that are supported by the 
client (Request #6658, requires Horde 3.3.7).

http://git.horde.org/diff.php/framework/SyncML/SyncML/Backend.php?rt=horde-git&r1=da4c5687690883de5668a2ce8bb7b279a815b6d1&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/framework/SyncML/SyncML/Backend/Horde.php?rt=horde-git&r1=da4c5687690883de5668a2ce8bb7b279a815b6d1&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/framework/SyncML/SyncML/Backend/Sql.php?rt=horde-git&r1=da4c5687690883de5668a2ce8bb7b279a815b6d1&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/framework/SyncML/SyncML/Sync.php?rt=horde-git&r1=da4c5687690883de5668a2ce8bb7b279a815b6d1&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/turba/docs/CHANGES?rt=horde-git&r1=67de2c3996a035d95275600459511b683caa25e8&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/turba/lib/Api.php?rt=horde-git&r1=f445d8031426da7c6c9bb5a68a100154aac8e113&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/turba/lib/Driver.php?rt=horde-git&r1=f4d219aaa36c4ec478c0a783223804210b006c9f&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc

Changes have been made in Git for this ticket:

Update deleted attributes during synchronization (lst_hoe02@kwsoft.de, 
Request #6658).

http://git.horde.org/diff.php/turba/docs/CHANGES?rt=horde-git&r1=beac6c49e29625d2ed42b6201f2af03165cd213f&r2=28297a3bb71e39fcf68d6751f287e4e7c8896923
http://git.horde.org/diff.php/turba/lib/Driver.php?rt=horde-git&r1=99d3ec3de78ee8fb862d211e2b330747a31aac23&r2=28297a3bb71e39fcf68d6751f287e4e7c8896923

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.

Changes have been made in Git for this ticket:

MFB: [jan] Only synchronize those fields that are supported by the 
client (Request #6658, requires Horde 3.3.7).

http://git.horde.org/diff.php/framework/SyncML/SyncML/Backend.php?rt=horde-hatchery&r1=da4c5687690883de5668a2ce8bb7b279a815b6d1&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/framework/SyncML/SyncML/Backend/Horde.php?rt=horde-hatchery&r1=da4c5687690883de5668a2ce8bb7b279a815b6d1&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/framework/SyncML/SyncML/Backend/Sql.php?rt=horde-hatchery&r1=da4c5687690883de5668a2ce8bb7b279a815b6d1&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/framework/SyncML/SyncML/Sync.php?rt=horde-hatchery&r1=da4c5687690883de5668a2ce8bb7b279a815b6d1&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/turba/docs/CHANGES?rt=horde-hatchery&r1=67de2c3996a035d95275600459511b683caa25e8&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/turba/lib/Api.php?rt=horde-hatchery&r1=f445d8031426da7c6c9bb5a68a100154aac8e113&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc
http://git.horde.org/diff.php/turba/lib/Driver.php?rt=horde-hatchery&r1=f4d219aaa36c4ec478c0a783223804210b006c9f&r2=f75d018f0e64f9ff29b3e0581613cc0f0bc616cc

Changes have been made in CVS for this ticket:

[jan] Only synchronize those fields that are supported by the client
(Request #6658, requires Horde 3.3.7).
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Backend.php?rt=horde&r1=1.8.2.19&r2=1.8.2.20&ty=u
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Backend/Horde.php?rt=horde&r1=1.8.2.18&r2=1.8.2.19&ty=u
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Backend/Sql.php?rt=horde&r1=1.6.2.7&r2=1.6.2.8&ty=u
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Sync.php?rt=horde&r1=1.8.4.23&r2=1.8.4.24&ty=u
http://cvs.horde.org/diff.php/horde/docs/CHANGES?rt=horde&r1=1.515.2.592&r2=1.515.2.593&ty=u
http://cvs.horde.org/diff.php/turba/docs/CHANGES?rt=horde&r1=1.181.2.246&r2=1.181.2.247&ty=u
http://cvs.horde.org/diff.php/turba/lib/Driver.php?rt=horde&r1=1.57.2.93&r2=1.57.2.94&ty=u
http://cvs.horde.org/diff.php/turba/lib/api.php?rt=horde&r1=1.120.2.68&r2=1.120.2.69&ty=u

Changes have been made in Git for this ticket:

Update deleted attributes during synchronization (lst_hoe02@kwsoft.de, 
Request #6658).

http://git.horde.org/diff.php/turba/docs/CHANGES?rt=horde-hatchery&r1=beac6c49e29625d2ed42b6201f2af03165cd213f&r2=28297a3bb71e39fcf68d6751f287e4e7c8896923
http://git.horde.org/diff.php/turba/lib/Driver.php?rt=horde-hatchery&r1=99d3ec3de78ee8fb862d211e2b330747a31aac23&r2=28297a3bb71e39fcf68d6751f287e4e7c8896923

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.

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.

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.

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

Changes have been made in Git for this ticket:

Update deleted attributes during synchronization (lst_hoe02@kwsoft.de, 
Request #6658).

http://git.horde.org/diff.php/turba/docs/CHANGES?rt=horde-hatchery&r1=beac6c49e29625d2ed42b6201f2af03165cd213f&r2=28297a3bb71e39fcf68d6751f287e4e7c8896923
http://git.horde.org/diff.php/turba/lib/Driver.php?rt=horde-hatchery&r1=99d3ec3de78ee8fb862d211e2b330747a31aac23&r2=28297a3bb71e39fcf68d6751f287e4e7c8896923

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 ??

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.

Are the array_key_exists() calls really necessary? Are those 
attributes really null (as opposed to empty strings), if not set?

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.

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.

Sounds great.

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...

Sounds good.

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.

Sorry, I don't follow what exactly you want to do under which conditions.
No, not yet.

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.

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.

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.

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??

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.

Testing always helps. Check if the patch still applies for you and 
works as expected.

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

Updated patch to current CVS HEAD.

This additional turba patch fixes empty attribute values for turba and 
ensures that empty vcard attributes are interpreted as "delete this 
attribute".

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.