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