On Sun, 2010-06-13 at 14:02 +0100, Frederik Elwert wrote:
I am just about to release the first version of Genesis after the
rewrite. There were some points I noticed where there is room for
improvement regarding the interplay between SyncEvolution, sync-ui and
Genesis. Some points have been mentioned before, so please excuse some
duplications, but I thought it would make sense to list all these issues
Yes, it does, thanks.
Watching for configuration changes (e.g., for refreshing the
list of servers in the GUI) currently is a bit cumbersome. It
requires watching for SessionChanged, request GetConfigs, and
look if the configs have changed. This is not really a problem,
but it might be more convenient to get notifications about
config changes directly.
Introduce a Server.ConfigChanged signal.
Problem: how does a client determine whether the signal is supported? It
is possible to request notifications for signals which are never going
to be sent because the daemon doesn't support them yet.
I think we need a org.syncevolution.Server.GetAPIRevision() method. It
should return a single integer. For each new addition to the API, the
revision gets increased. If we ever have to break the API, we move to
"org.syncevolution" and "/org/syncevolution/Server2" with a revision
that starts again at 1. If we can, we should continue to support both
the old and the new API.
Not having that GetAPIRevision() method implies revision 1 of the
While we are at it, we should also add a Server.GetVersion() method
which returns the SyncEvolution release version and auxiliar
information, similar to "syncevolution --print-version".
GUIs cannot tell for which server a session was started if the
GUI didn’t start the session itself. So for example when Genesis
sees that a sync session ended and displays the results, it
cannot tell (and therefore cannot show to the user) which server
was actually affected. So e.g. notifying about the results of
automated syncs lacks some rather important information.
Introduce a Session.GetServerName() method.
The syncevo-dbus-server handles user notifications itself (e.g.
for automated syncs.) A GUI might want to notify users about
syncs itself. E.g. Genesis shows a spinning status icon, which
makes the sync started/sync ended notifications of
Clients should be able to tell syncevo-dbus-server not to
display sync notifications. I propose a method
Server.InhibitNotification(bool) which could be used to inhibit
notifications when Genesis is started and allow notifications
before it terminates.
Okay. But we need to deal with the situation that the client which
called Server.InhibitNotification(true) dies without removing the lock.
This is already covered by Server.Attach/Detach(). The effect is that
while a client is attached, the server won't shut down. This simplifies
the implementation, because storing persistently whether a lock was set
and by which client can be avoided.
Genesis no longer ships its own configuration facilities, but instead
uses sync-ui for this. In general, sync-ui is more powerful than
Genesis’ old setup assistant. But if I didn’t oversee something, it is
currently not possible to set evolutionsource.
Correct. It's one of the design simplifications inherited from the
There might be situations
where one wants to sync other sources than the default ones, e.g. when
syncing the private calendar with one service, and the work calendar
with another one.
It would be nice if one could choose the sources in sync-uis settings
dialog. Maybe it would make sense to rename the “show server settings”
expander to something like “show extended settings” and allow to select
the data sources there.
I agree. However, unless someone from the community submits patches for
this *and* they do not affect the Moblin/MeeGo build, this won't get
added to the sync-UI.
I just noticed that syncevolution commandline commands (like
--print-config or --print-sessions) are treated as syncs in the GUIs
(sync-ui, Genesis). This is because the GUIs watch for
Session.StatusChanged and expect that a sync was performed with
status==done. Even commandline errors (like not giving a server name
where required) is treated like a sync error in the GUIs.
I don’t know at which point this could be solved. Are there means for
the GUIs to tell if a session was a sync session or something else? If
not, should the API be extended to cover this? Or could simple the
commandline client be changed not to trigger SessionChanged signals?
That the command line runs inside a Session is by design and cannot be
changed. It might be possible to add a method to a Session which
identifies for what purpose it was created. This implies that
StartSession() needs different parameters - need to check how to extend
the API here.
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.