[sync] Trouble keeping SyncML in sync with IMAP store

[Gunnar Wrobel]

Jan Schneider <jan <at> horde.org> writes:

> 
> Zitat von Gunnar Wrobel <p <at> rdus.de>:
> 
> > Jan Schneider <jan <at> horde.org> writes:
> >
> >>
> >> Zitat von Jan Christoph Ebersbach <ebersbach <at> univention.de>:
> >>
> >> > Good morning,
> >> >
> >> > I'm experiencing some trouble keeping a mobile device in sync  
> >> with data that
> >> > is stored in an IMAP folder. I.e. creating an event with  
> >> Kontact-Calendar and
> >> > trying to sync this event with my mobile device causes SyncML to  
> >> think that
> >> > there is no new event in the IMAP folder.
> >> >
> >> > I tracked the problem down to a missing entry in the horde_histories table
> >> > which is not updated by the SyncML implementation at the moment.  
> >> Btw, when I
> >> > open the calendar in kronolith the missing entry is added automatically.
> >> >
> >> > I wrote a small patch to work around this problem by syncing the  
> >> IMAP folder
> >> > every time a SyncML-sync is performed. So far there is still a  
> >> problem with
> >> > syncing the IMAP folder this way because the changes are not  
> >> included in the
> >> > current but the next SyncML sync.
> >> >
> >> > Do you have any suggestions solving this problem in a better way?
> >>
> >> This is definitely not the correct way. The history entries have to be
> >> created directly in the drivers. In some cases this already happens
> >> either outside the drivers or in the driver parent class. Where this
> >> is not the case, it has to happen in the Kolab drivers, just like we
> >> do in the other drivers already.
> >
> > I think Jan Christoph did refer to the problem we already discussed  
> > briefly on
> > the dev mailing list (http://thread.gmane.org/gmane.comp.horde.devel/16954).
> >
> > You seem to refer to the SQL driver in your answer as this storage  
> > system only
> > allows for Horde as a client. If a storage backend allows modifications from
> > external clients this is a different story though. The Horde history  
> > system will
> > not catch external modifications at the moment.
> 
> No, this has nothing to do with the SQL driver. It's just about where  
> certain code belongs.
> 

True, the code for that should not be in the listBy() function.

> > I think the submitted patch is still a little bit too direct but in  
> > principle it
> > goes into the right direction. I believe that we need to fix the  
> > listBy() call
> > with a synchronization method so that the backend can check for external
> > modifications.
> 
> This still doesn't belong in the API.

Not in the API at all?

> If some Horde backends require a  
> history update before the actual synchronization, we can initiate such  
> an update from SyncML_Backend_Horde.

Yes, indeed. But that would need to call the API of the database that is
currently being accessed via SyncML or am I missing something? It might be an
additional API function rather than listBy() but otherwise the Horde SyncML
backend would need additional knowledge about the actual storage backend used.

> Though I can't imagine how this  
> should be reliably working if it doesn't happen right when the data  
> changes.

External modifications to the storage do in some parts violate the Horde History
concept as the timing of a change can't be precise anymore. For SyncML this does
not seem to be a problem though as we only ask if there was a change during a
certain time period. As long as the code ensures that all change timestamps are
in the correct time periods SyncML is fine. And that should work fine as long as
SyncML calls storage synchronization right before determining the next anchor
points for the time period.

I have to admit though that the longer I work with SyncML and Kolab that I see
more and more drawbacks and don't consider it an optimal solution. But as long
as we don't have native Kolab clients on the mobile devices SyncML is at least a
workaround.

Cheers,

Gunnar


> 
> Jan.
>