2:02 p.m.
Hello!
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.
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.
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.
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.
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. 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.
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?
I don’t know if these changes are possible, but I’d be happy to hear
your feedback to these issues.
Regards,
Frederik
10:10 a.m.
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.
9:50 p.m.
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-ge...
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
9:14 a.m.
On Thu, 2010-06-17 at 21:50 +0100, Frederik Elwert wrote:
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-ge...
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.
I like that better, too. For example, it allows us to backport API
features, which would not be possible if the API revisions had to be
strictly linear.
I'll start filing issues with API proposals.
--
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.
1:42 p.m.
On Fr, 2010-06-18 at 09:14 +0100, Patrick Ohly wrote:
I'll start filing issues with API proposals.
Below a summary of the proposed enhancements. Does that sound right? Do
we need additional flags for starting a session, beyond the "not for
sync"?
How urgent is this, in other words, who wants to use these extensions at
which point in time?
Bug 3558 - D-Bus: add Server.ConfigChanged signal
<signal name="ConfigChanged">
<doc:doc>
<doc:description>
Configuration added, updated or removed To find out more, request
list of configurations anew.
</doc:description>
</doc:doc>
</signal>
Bug 3559 - D-Bus: add Session.GetConfigName() method
<method name="GetConfigName">
<doc:doc>
<doc:description>
<doc:para>Get the configuration name of the session.</doc:para>
<doc:para>Every session is associated with a specific
configuration, as requested by the creator of the session. This call
returns the normalized configuration name. Note that this may be different
from the name used when creating the configuration, because that name
is not required to be normalized. Therefore this method may be useful
both for the creator of the session and other clients which cannot
know the configuration name without calling this method.</doc:para>
</doc:description>
</doc:doc>
<arg type="s" name="config" direction="out">
<doc:doc><doc:summary>peer configuration
name</doc:summary></doc:doc>
</arg>
</method>
Bug 3560 - D-Bus: suppress notifications on demand
Instead of a simple boolean, let's keep the option open to enable and
disable specific notifications. Thus adding a string parameter and two
methods:
<method name="DisableNotifications">
<doc:doc>
<doc:description>
Prevents showing of user visible notifications by the syncevo-dbus-server.
Must be called while the client is attached to the server. Notifications
will be disabled until the client detaches or calls UnlockNotifications().
</doc:description>
</doc:doc>
<arg type="s" name="notifications"
direction="in">
<doc:doc><doc:summary>
describes the notifications which are to be disabled; currently
ignored by server, pass empty string
</doc:summary></doc:doc>
</arg>
</method>
<method name="EnableNotifications">
<doc:doc>
<doc:description>
Allows showing of user visible notifications again.
</doc:description>
</doc:doc>
<arg type="s" name="notifications"
direction="in">
<doc:doc><doc:summary>
describes the notifications which are to be ensabled; currently
ignored by server, pass empty string
</doc:summary></doc:doc>
</arg>
</method>
Bug 3562 - D-Bus: sessions for a specific purpose
<method name="StartSession">
<doc:doc><doc:description>
Start a session. The object is created instantly but will not be
ready for method calls until status changes from "queueing" to
"idle".
The Detach() method can be called before that.
</doc:description></doc:doc>
<arg type="s" name="server" direction="in">
<doc:doc><doc:summary>server name</doc:summary></doc:doc>
</arg>
<arg type="o" name="session" direction="out">
<doc:doc><doc:summary>session D-Bus object
path</doc:summary></doc:doc>
</arg>
</method>
<method name="GetFlags">
<doc:doc>
<doc:description>
Get the session flags set with Server.StartSessionWithFlags().
</doc:description>
</doc:doc>
<arg type="a{s}" name="flags" direction="out">
<doc:doc><doc:summary>session
flags</doc:summary></doc:doc>
</arg>
</method>
Bug 3563 - D-Bus: self description of features
<method name="GetCapabilities">
<doc:doc>
<doc:description>
<doc:para>
Describes which features are implemented by the server. If the method itself
is unavailable, then the features correspond to SyncEvolution 1.0. The
following
capabilities are currently defined:
<doc:list>
<doc:item><doc:term>ConfigChanged</doc:term><doc:definition>Server.ConfigChange
signal available; if not, reread config after each
session</doc:definition></doc:item>
<doc:item><doc:term>GetConfigName</doc:term><doc:definition>Session.GetConfigName()
implemented</doc:definition></doc:item>
<doc:item><doc:term>Notifications</doc:term><doc:definition>Server.DisableNotifications()
and Server.EnableNotifications() implemented</doc:definition></doc:item>
<doc:item><doc:term>Version</doc:term><doc:definition>Server.GetVersion()
implemented; note that this is not meant to be used to determine supported
features</doc:definition></doc:item>
<doc:item><doc:term>SessionFlags</doc:term><doc:definition>Server.StartSessionWithFlags()
and Session.GetFlags() are implemented</doc:definition></doc:item>
</doc:list>
</doc:para>
</doc:description>
</doc:doc>
<arg type="a{s}" name="capabilities"
direction="out">
<doc:doc><doc:summary>
set of supported capabilities
</doc:summary></doc:doc>
</arg>
</method>
<method name="GetVersions">
<doc:doc>
<doc:description>
<doc:para>
Returns information about server side implementations.
</doc:para>
</doc:description>
</doc:doc>
<arg type="a{ss}" name="info" direction="out">
<doc:doc><doc:summary>
"version" - main SyncEvolution release name (usually a number,
sometimes also a beta or alpha suffix),
"system" - some plain text information about system libraries,
"backends" - available backend libraries
</doc:summary></doc:doc>
</arg>
</method>
--
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.
10:40 p.m.
Am Montag, den 28.06.2010, 14:42 +0200 schrieb Patrick Ohly:
On Fr, 2010-06-18 at 09:14 +0100, Patrick Ohly wrote:
> I'll start filing issues with API proposals.
Below a summary of the proposed enhancements. Does that sound right?
Looks all right, thanks for picking up my proposals!
Do
we need additional flags for starting a session, beyond the "not for
sync"?
Hm, I couldn’t find the flags defined for StartSessionWithFlags.
Originally, I thought this could also be used for starting sync
sessions. As I discussed earlier with Jussi (and if I understood
everything correctly), there is an inherent race condition in the way
sync sessions are created, because one has to request the session, then
connect to the SessionChanged signal and launch the sync once the
SessionChanged signal comes in (which might be before the signal was
connected).
So I thought one could work around this by calling a session with a
"meant for sync" flag, but then a client would also have to know that a
particular session was requested by itself, not by another client.
So this was probably a bad idea, and it is enough to know that a session
was not meant for syncing, as proposed. Sorry for thinking aloud, I just
thought I might have overlooked something that someone else can see
clearer.
How urgent is this, in other words, who wants to use these extensions
at
which point in time?
For me (and Genesis) all this is not really urgent. It currently works,
so this would be welcome polish, but not really new features. (Maybe
except for the Session.GetConfigName() method, since this might be a
relevant information that is currently lacking from sync reports.)
Once syncevo-dbus-server implements these (and binary pre-releases are
available, I’m too lazy for building it myself ;)), I’ll implement the
corresponding functionality in Genesis. So no hurry from my side.
Cheers
Frederik
7:34 a.m.
On Mon, 2010-06-28 at 22:40 +0100, Frederik Elwert wrote:
Am Montag, den 28.06.2010, 14:42 +0200 schrieb Patrick Ohly:
> On Fr, 2010-06-18 at 09:14 +0100, Patrick Ohly wrote:
> > I'll start filing issues with API proposals.
>
> Below a summary of the proposed enhancements. Does that sound right?
Looks all right, thanks for picking up my proposals!
Thanks for making them! An API (only?!) becomes better once different
people try to use it... and provide feedbacks.
> Do
> we need additional flags for starting a session, beyond the "not for
> sync"?
Hm, I couldn’t find the flags defined for StartSessionWithFlags.
I copied the old "StartSession" method instead of the new one. Here it
is:
<method name="StartSessionWithFlags">
<doc:doc><doc:description>
Start a session. The object is created instantly but will not be
ready for method calls until status changes from "queueing" to
"idle".
The Detach() method can be called before that. Additional flags,
identified by strings, can be passed to control the session creation.
They can be retrieved with Session.GetFlags(). The following flags are
currently defined:
<doc:list>
<doc:item><doc:term>no-sync</doc:term><doc:definition>session will
not be used for running a synchronization</doc:definition></doc:item>
</doc:list>
</doc:description></doc:doc>
<arg type="s" name="config" direction="in">
<doc:doc><doc:summary>configuration
name</doc:summary></doc:doc>
</arg>
<arg type="a{s}" name="flags" direction="in">
<doc:doc><doc:summary>optional
flags</doc:summary></doc:doc>
</arg>
<arg type="o" name="session" direction="out">
<doc:doc><doc:summary>session D-Bus object
path</doc:summary></doc:doc>
</arg>
</method>
Originally, I thought this could also be used for starting sync
sessions. As I discussed earlier with Jussi (and if I understood
everything correctly), there is an inherent race condition in the way
sync sessions are created, because one has to request the session, then
connect to the SessionChanged signal and launch the sync once the
SessionChanged signal comes in (which might be before the signal was
connected).
So I thought one could work around this by calling a session with a
"meant for sync" flag, but then a client would also have to know that a
particular session was requested by itself, not by another client.
So this was probably a bad idea, and it is enough to know that a session
was not meant for syncing, as proposed. Sorry for thinking aloud, I just
thought I might have overlooked something that someone else can see
clearer.
I think you covered this well.
--
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.
4339
days inactive
4355
days old
syncevolution@synevolution.org
6 comments
2 participants
participants (2)
-
Frederik Elwert -
Patrick Ohly