On Fri, 2011-11-04 at 16:02 +0100, Patrick Ohly wrote:
> Now this could be a case of "to remove a value, explicitly send an empty
> one". The encoder in the activesyncd doesn't do that at the moment. Need
> to check. 

Code is in activesyncd, test is in SyncEvolution.


commit 6ee6f7a4af8c31e505dd7183ee6fe2e43c35e174
Author: Patrick Ohly <[email protected]>
Date:   Thu Nov 24 13:35:52 2011 +0100

    calendar + contact: support removal of previously set properties
    
    Certain properties are not removed by the server in its own database
    unless the client explicitly sends an empty XML tag for the property.
    Because the activesyncd daemon doesn't know which properties the
    server currently has, all it can do is send empty (or default) values
    for everything that it may or may not have set in the past.
    
    Done also for adding items, just in case.
    
    In WBXML encoding the extra data should be fairly limited.
    
    An almost complete test for contacts and calendar is the new
    SyncEvolution testRemoveProperties. It does not cover removal of
    RRULE+EXDATE+detached recurrence because that cannot be done with
    a purely mechanical removal of individual properties.
    
    There are some known limitations:
    - there is no "item does not recur" RRULE, so no empty RRULE is
      added; it is untested whether that is necessary
    - removing exceptions is not implemented, see comments in the patch
      and BMC #24290
    
    The ActiveSync data schema allows some elements only in the
    parent (all-day, attendees). Other's are allowed in exceptions, but
    only if they have a content (categories). As a result, an exception
    cannot override all of its parent's properties (which is a problem if
    the iCalendar 2.0 data happens to do that!) and removing such
    properties (if set before) also isn't possible.
    
    The SyncEvolution tests pass because they happen to avoid these corner
    cases.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to