http://bugzilla.moblin.org/show_bug.cgi?id=6378
--- Comment #30 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-26 21:13:51
PST ---
(In reply to comment #29)
(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?
currently we don't need this kind of detail(only know it does change).
but I
don't know whether there are other requirements for this.
> 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.
good, If a backend don't support
listener and we add a listener, it should
throw some kind of exception.
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
If we don't use open(), for evolution, we
can't listen changes. maybe backend
should be in charge of this itself.
- a source is used either for change notifications or data access
ok, a source is for one functionality one time
- it only has to support at most one listener
why has this
limitation?
- 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
ok, good
declarations.
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.
Yes,
you are right. Is it possible to add a mechanism to give opportunites of
backends to handle their changes?
--
Configure bugmail:
http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.