Am Donnerstag, den 17.06.2010, 11:10 +0200 schrieb Patrick Ohly: > 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 > > here. > > Yes, it does, thanks. > > > API issues > > > > Problem: > > 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. > > Proposed solution: > > Introduce a Server.ConfigChanged signal. > > Agreed. > > 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 > current API.
Yes, once the API is changed, clients should be able to find out which API the server supports. The notification daemon has a GetCapabilities() method, which returns an array of strings: http://www.galago-project.org/specs/notification/0.9/x408.html#command-get-capabilities Personally, I somehow like this approach better than telling the API revision. It is more verbose and allows to see if a specific feature is supported. If only the API revision is reported, the client has to have knowledge of which revision contains which features. > 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". Right, this would be useful. > > Problem: > > 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. > > Proposed Solution: > > Introduce a Session.GetServerName() method. > > Agreed. > > > Problem: > > 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 > > syncevo-dbus-server redundant. > > Proposed Solution: > > 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. > > > Sync-UI > > > > 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 > Netbooks. > > > 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. Sure, I understand. Unfortunately, I don’t know C++, so someone else would have to jump in here. :-) > > syncevolution commandline > > > > 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. I definitely like this idea. Not knowing what purpose a session was created for kept bothering me, and I still think the current solutions are less than perfect. And if this also provides a means to sort out commandline sessions, great! Regards, Frederik _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
