[Syncevolution-issues] [Bug 6378] automatic sync

(In reply to comment #27) > syncevolution should have a mechanism to detect backends changes, here is a > proposal: > 1) Define a new class SyncSourceListener, used to track backends changes. 3 > virtual methods are acted as callbacks of change signals. > class SyncSourceListener { > public: > /** itemAdded is a callback when an item is newly added by backend */ > virtual void itemAdded(const string &luid, const string &item, bool raw) {}; > /** itemRemoved is a callback when an item is newly removed by backend */ > virtual void itemRemoved(const string &luid) {}; > /** itemChanged is a callback when an item is newly changed by backend */ > virtual void itemChanged(const string &luid, const string &item, bool raw) {}; > }; I'm not sure whether we need this level of detail. It makes implementing change notification harder in the backends. What would the "bool raw" parameter mean anyway?

> 2) Add a virtual method in TrackingSyncSource: > class SyncSource { > public: > ... > /** > * Register a listener to listen to backend changes > * Each backend can implement this if it has the ability > * to track backend changes. > * If the listener is registered successfully, return true > */ > virtual bool addListener(SyncSourceListener *listener) > { > return false; > } > }; What about exceptions? The caller has to be prepared for those anyway, so we might as well just remove the "bool" return and use exceptions for reporting failures.

In the description above it is not clear how that fits into the life cycle of a SyncSource. Is it encapsulated by open() and close()? Does a source have to be prepared to handle sync at the same time as change notifications? I think we should specify that: - open()/close() are not called

- a source is used either for change notifications or data access

- it only has to support at most one listener

- changes made by SyncEvolution as part of a sync may be reported, but don't have to - the listener instance is owned by the caller - the source should continue monitoring changes until destructed

A prototype of "void startListening(SyncSourceListener &listener)" might fit that semantic better.

Another unclear aspect is when the callbacks are allowed to happen and what triggers them. We have to be aware that currently, only backends which integrate into the glib main loop have a chance to do change notifications.