[sync] Deleting attributes on the client

[Jan Schneider]

Zitat von Gunnar Wrobel <p at rdus.de>:

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

I don't think the device-specific handling is a good approach in this  
case, because I expect the supported attributes to be different from  
model to model, and I don't really want to start differentiating  
between different brand models in the code.

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

Sounds like a plan.

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

See above.

> I'd prepare the required patches in that case.

Great. The question is how to add the missing empty attributes to  
objects sent from the client. I guess we could parse the data into  
Horde_iCalendar objects, add the missing attributes, serialize them  
back into a string and then pass them to the apps that would parse  
them once again. Sounds awkward.

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

Yeah, exactly. My best guess would be to take a look at the iTip RFC  
because it's about exchanging data using the iCalendar format.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/