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. 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". > 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. > 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. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
