[sync] Deleting attributes on the client

Thu Apr 3 11:43:09 UTC 2008

Hi Jan,

thanks for the feedback!

Jan Schneider <jan at horde.org> writes:

> Zitat von Jan Schneider <jan at horde.org>:
>
>> Zitat von Gunnar Wrobel <p at rdus.de>:
>>
>>> Hi!
>>>
>>> I'm currently testing SyncML support with Horde CVS HEAD based on a
>>> Kolab backend (IMAP based data storage). The SyncML part is based on
>>> SQL though. Clients are a Blackberry and a Nokia 6120c.
>>>
>>> In general both work fine wich is nice :) But I'm unable to delete
>>> attributes on either of the clients (e.g. removing an e-mail address
>>> or a phone number in an already synchronized addressbook entry on the
>>> client). The data remains present on the server after removing the
>>> attribute and synchronizing.
>>>
>>> This seems to come down to a problem with data exchange via
>>> vCard/iCalendar. I'm not certain how things are supposed to work.
>>>
>>> Both clients will send vCard/iCalendar data wich contains only
>>> attributes that actually have a value on the client. So if I delete an
>>> attribute in a vCard it won't be mentioned in the update message from
>>> the client.
>>>
>>> As te vCard has been exchanged between client and server before Turba
>>> will fetch the old entry and overwrite any attributes provided by the
>>> client on this addressbook entry.
>>>
>>> As I deleted the attribute the change will be missed by the server.
>>>
>>> Turba will delete an attribute if the attribute is provided with an
>>> empty string as value. Is this the intended behaviour? Meaning that
>>> the client update must indicate removal of an attribute by sending the
>>> attribute with an empty value?
>>>
>>> As the clients don't do that I would need to use a client specific
>>> converter but that would be fine. I'm just wondering whether that is
>>> the intended mode of action. In fact using vCards/iCalendars as method
>>> of data exchange seems somewhat limited in that context. But that
>>> would be a SyncML limitation then.
>>
>> This is a very special problem limited to Turba. The problem is, that
>> both could happen: we have attributes in Turba that are not supported
>> by vCard or the sync client, or we have vCard attributes that are not
>> supported by Turba.

Not necessarily. You get the same problem with recurrence in Kronolith
for example. That's why I initially commited the small change for
deleting recurrence information in the kronolith driver
(http://cvs.horde.org/kronolith/lib/Driver.php) which I reverted later
because I realized that I'd introduce problems with clients that don't
know anything about recurrence and would never send that attribute.

>>
>> If we simply overwrite the contacts in Turba with the updated contact
>> from the client, all special attributes from the Turba contact would
>> disappear. This is obviously not what we want.

Yep.

>>
>> I'm not sure how to deal with that. Maybe we could try to determine
>> the vCard attributes that would have been supported by Turba and
>> overwrite those unconditionally. But this seems fragile, since it
>> would still delete attributes from Turba that are supported by vCard,
>> but not by the client.
>
> Actually this is not exactly true. IIRC some clients send a list of  
> vCard/iCalendar attributes that they support. This could probably be  
> used to build a complete list of attributes, with those set to empty  
> that are missing.

Yes, we have those. The Blackberry sends the full list of supported
attributes in vcards and icalendar data. The Nokia on the other hand
does not. But even in this case we can still determine that there is a
Nokia client and handle the problem in a special Nokia Device class
within SyncML (This already exists but it does not care for empty
attributes yet). Such a class could simply check which attributes are
set and fix the unset ones which are known to be suppoerted by the
client by setting them to an empty string.

Turba and the other Horde apps on the other hand would be required to
do the same. Turba actually already does that but Kronolith still has
some problems there (if recurrence is unset the resulting icalender
won't have the attribute).

But in principle you think this would be the way to go? So we'd
require the SyncML communication partners to set all vcard/icalendar
attributes that are supported by that communication partner. An empty
string value in an attributes indicates to the other side that this
attribute should get deleted.

For SyncML clients we handle problems with clients that don't support
this scheme within a specific device class.

I'd prepare the required patches in that case.

I'm still wondering if there is any document describing how this is
supposed to work. SyncML doesn't really talk about this as it is only
concerned with the protocol and not with the data actually being
exchanged.

Cheers,

Gunnar

>
> Jan.
>
> -- 
> Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
>
> -- 
> sync mailing list - Join the hunt: http://horde.org/bounties/#sync
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: sync-unsubscribe at lists.horde.org
>

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   >> Mail at ease - Rent a kolab groupware server at p at rdus <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~