[SyncEvolution] D-Bus API: interactive password requests
by Patrick Ohly
Hello!
Here's a more formal description of the D-Bus server<->clients (plural!)
interface for user dialogs or other information provisioning by clients.
I have pushed the description to the dbus-api branch. If this is okay,
then I'll also add stubs to the server's source code.
I know that the "'source name' backend" string will be difficult to
localize. Feel free to ignore this, almost none of the backends
currently need it. Only very advanced usages like accessing Exchange via
EDS currently do.
<signal name="InfoRequest">
<doc:doc>
<doc:description>
<doc:para>
Emitted whenever the server needs information that only a
client can provide. Because the server does not know whether
clients are monitoring it (attaching to the server is
optional) and/or which of the attached clients are able to
handle the request, it broadcasts the request.
</doc:para>
<doc:para>
Clients respond by calling InfoRequest. The flow is this:
information needed, InfoRequest("request"),
InfoResponse("working") + dialog is opened (if necessary),
InfoRequest("waiting"), information becomes available,
InfoResponse("response"), InfoRequest("done").
</doc:para>
<doc:para>
Clients should work on those requests that they support,
unless another client was faster (InfoRequest("waiting")).
Because there is a race condition, multiple dialogs might
be opened. The user only has to enter data in one of them.
A client can close his dialog upon InfoRequest("done")
and/or InfoRequest("waiting") with a 'handler' parameter
which is some other client. If the server does not get a
InfoResponse("working") soon enough (in the range of
minutes, not seconds), it has to assume that no client can
provide the information and fall back to some default or
abort.
</doc:para>
</doc:description>
</doc:doc>
<arg type="s" name="id">
<doc:doc><doc:summary>unique ID for the request</doc:summary></doc:doc>
</arg>
<arg type="o" name="session">
<doc:doc><doc:summary>the Session which is affected, may be empty</doc:summary></doc:doc>
</arg>
<arg type="s" name="state">
<doc:doc>
<doc:summary>
"request" for a new request,
"waiting" for one which is being serviced by some client,
"done" for a request which was resolved or timed out
</doc:summary>
</doc:doc>
</arg>
<arg type="o" name="handler">
<doc:doc>
<doc:summary>
for state="waiting": the client which first replied
with InfoResponse("working")
</doc:summary>
</doc:doc>
</arg>
<arg type="s" name="type">
<doc:doc>
<doc:summary>
Determines which information is needed. Currently only
"password" for interactive password requests is defined.
</doc:summary>
</doc:doc>
</arg>
<arg type="a{ss}" name="parameters">
<doc:doc>
<doc:summary>
Auxiliary parameters which depend on the type.
For "password" the following keys are used:
"name" - name of the password property in the config.
"description" - unique English description of the required password.
Content is determined by the individual password property, so this
may change. Currently used are "SyncML Server", "proxy",
"'source name' backend" (with 'source name' replaced by the same
names also used for the corresponding config entry).
"user", "server", "domain", "object", "protocol", "authtype", "port" -
optional keys as they would be used in the GNOME keyring.
</doc:summary>
</doc:doc>
</arg>
</signal>
<method name="InfoResponse">
<doc:doc><doc:description>reply for a specific InfoRequest</doc:description></doc:doc>
<arg type="s" name="id">
<doc:doc><doc:summary>unique ID sent by InfoRequest</doc:summary></doc:doc>
</arg>
<arg type="s" name="state">
<doc:doc>
<doc:summary>
"working" to indicate that a response will be sent later,
"response" for the actual reply
</doc:summary>
</doc:doc>
</arg>
<arg type="a{ss}" name="response">
<doc:doc>
<doc:summary>
Response values, valid in state="response", depend on type.
For "password" the following keys are used:
"password" - the password text, optional, do not set the key if the
user cancelled the request
</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.
11 years, 12 months
Re: [SyncEvolution] D-Bus API: availability of local sources (was: syncevo-dbus-server implementation)
by Patrick Ohly
On Fri, 2009-09-18 at 06:06 +0100, Zhu, Yongsheng wrote:
> Another issue from dbus interface is:
> | "Cleared" in this context means that all existing
> | properties are removed before setting those passed as
> | argument.
>
> The properties which are removed are commented and not set with empty string?
They are wiped out completely. Basically "Cleared" means "remove
everything from "config.ini" and then fill the file with the properties
which were sent by the D-Bus client.
> | Configuration entries (the user-visible part as
> | well as the related meta information, plus the containing
> | directory if it is empty) which are not referenced by a
> | key in the configuration are removed.
>
> If any settings for 'addressbook', then 'addressbook' directory will be removed?
If there are no settings for 'addressbook', then all SyncEvolution files
in the 'addressbook' directory can be removed, including the directory
if it is empty afterwards. See the implementation of the --remove
options for an example how this is currently done.
--
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.
11 years, 12 months
[SyncEvolution] D-Bus API: session ID
by Patrick Ohly
Hello Forrest!
The main reason for making the session ID in the D-Bus API an uint32_t
was that this might have allowed obexd to map this to the OBEX
connection ID. As we discussed, this doesn't work.
Therefore I think we can change that part of the API. I'd like to turn
uint32_t into a string, to make the range of valid session IDs broader
(required if Synthesis server chooses it).
In practice, the session ID will only be used to re-establish a
connection, in other words, in the initial Process() call. This isn't
part of the API contract at the moment. Should we document it and thus
allow obexd to completely ignore the session ID?
I can make the change now, but don't want to ruin the first round of
testing between obexd and SyncEvolution without giving advance
warning...
--
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.
11 years, 12 months
[SyncEvolution] cmdline --keyring --print-config: should it show real password or "-"?
by Patrick Ohly
Hello!
While testing Yongsheng's implementation of keyring support in the
command line I ran into a case where I'd like to get some opinions: when
the passwords are stored in the keyring, the config contains "-" instead
of the real password.
When invoked with "--keyring --print-config", should the command line
retrieve the password from the keyring and present it to the user? I'm
undecided about this myself. On the one hand, the password is no longer
part of the configuration. On the other hand, the password cannot be
shown via the command line even if the user wanted that.
He has to know about keyring and the "seahorse" tool to view the
keyring, then look for the password entry. Definitely not something for
novice users.
Therefore I tend to think that the password should be retrieved if
available when --keyring is stored, without triggering an interactive
request for the password if not. Would make "checkPassword()" more
tricky, of course.
--
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.
11 years, 12 months
[SyncEvolution] git merging + open issue around "status 200 as 201 for Replace cmd"
by Patrick Ohly
Hello!
I updated the SyncEvolution master branch so that it directly uses
Lukas' branch, with once exception: I kept Congwu's patch "client +
statistics workaround: treat status 200 as 201 for Replace cmd (which is
really an Add)".
Lukas said in his revert commit that "Permanent fix is discussed and in
the works." Who is working on it, and do we have a bug tracker entry for
it?
Congwu posted a patch for it on this email:
From: Chen, Congwu <congwu.chen(a)intel.com>
To: Lukas Zeller <luz(a)synthesis.ch>
Cc: Synthesis <os-libsynthesis(a)synthesis.ch>
Subject: Re: [os-libsynthesis] Your "client+statistics workaround" patch (f51c0bc3a77d29b5af33c5003b4752173ed35ddb in moblin git)
Date: 08/19/2009 12:04:16 PM (Wed, 19 Aug 2009 11:04:16 +0100)
I suspect that this patch still needs to be integrated. It no longer
applies cleanly. Congwu, can you check what needs to be done and if we
don't have an entry on our Bugzilla, create one?
--
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.
12 years
[SyncEvolution] moving developer content to syncevolution.org
by Patrick Ohly
Hello!
I have started the process of relocating content from
moblin.org/projects/syncevolution to syncevolution.org. There is now a
new top-level link "Development" for development-oriented content.
The main page has information that hopefully is useful for prospective
contributors. I intend to create sub-pages with other technical
material, starting with the two articles which are currently still on
moblin.org.
All SyncEvolution developers should be able to create content there.
However, at the moment the registration feature on the site is disabled
(there are some issues with the password recovery feature), so I have to
create accounts manually.
Congwu's article about Bluetooth test setup is another candidate for
that category.
Please mail me your preferred account names and I'll create the
accounts.
--
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.
12 years
[SyncEvolution] status 2009-10-17
by Patrick Ohly
Hello!
Busy times... ;-)
Merged all pending patches for improving interoperability with more
servers (Mobical, Memotoo) into master branch in preparation for 0.9.1.
As is often the case, the testing with Memotoo found several issues in
the server, which were fixed quickly. Message resending suffered from
one problem with misbehaving servers (endless loop with Funambol-based
servers), which we have a work around for now. Synthesis has reviewed
and merged all of our patches, too.
Translations for 0.9/Moblin 2.0 in translate.moblin.org are now done on
a maintenance branch, so we made our string changes for 0.9.1 on the
master branch. We'll continue to work towards 0.9.1 on master for
another week or so before releasing a snapshot and starting testing.
The open issues for 0.9.1 are (most important first):
* Congwu, 3427 - poor usability with network interruption: resend
messages
* Yongsheng, 3604 - command line: use keyring
* Congwu, 6127 - workaround for 200 vs 201 status codes + Replace
instead of Add
* Jussi, 5871 - unsupported and unavailable data categories
(Google calendar/task/memo)
* Congwu, 6181 - Package SyncEvolution core as a library for third
party developers
* Memotoo + Yongsheng, 5635 - test and support Memotoo
* Jussi, 5717 - sync UI needs to set an icon for its window
* Jussi, 5219 - Add a Service with 200 chars of name,
syncevolution-dbus has corewatcher
Some of these have patches pending or just need testing, so there is
some work left for me, besides writing the release notes ;-)
During the face-to-face in London Jussi, Nick, Patrick, Tom Counihan
(Intel's representative at GENIVI) talked about sync. It was a very
productive meeting: lots of ideas for next steps and things to
implement... In general, the wish list for 1.0 increased instead of
decreased during the meeting.
Regarding sync : we identified that automatic syncs are
expected soon, because they make sync really useful in the
Moblin usage models. Manual intervention should only be necessary when
something went wrong. We were already working towards that goal (EDS API
changes, sync server without GUI, recovery mode), but we didn't have it
on our feature list for SyncEvolution 1.0. The biggest gap is in the
GUI.
My proposal is to work towards a 1.0 alpha with the features as planned
so far (minimal changes in GUI, direct device-to-device sync), then
re-evaluate whether we release it as 1.0 or continue adding the missing
features.
Development:
* Yongsheng: keyring support (#3604), nightly testing, Memotoo
interoperability
* Congwu: article about extending SyncEvolution for the SDK,
libsyncml patching for testing with OBEX, outgoing OBEX
connections, Alert 222 loop detection.
* Jussi: UI D-Bus proposal
* Patrick: UI D-Bus proposal refinement, partial implementation in
new syncevo-dbus-server, investigated build failure of
SyncEvoluion 0.9 in Moblin trunk (root cause: invalid type in
libsoup, reported and resolved now)
Noteworthy new issues:
* Users have reported problems with the Horde (server sends
invalid XML, WBXML works) and eGroupware (doesn't support WBXML,
sync does not complete) servers. Currently we are not testing
against those.
--
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.
12 years
[SyncEvolution] desktop platform dependencies in syncevo-dbus-server: keyring, network monitoring
by Patrick Ohly
Hello!
In issue 3604 "command line: use
keyring" (http://bugzilla.moblin.org/show_bug.cgi?id=3604) we debated
whether and where we can depend on desktop platform specific technology
like the GNOME keyring.
My position was (and still is) that the core SyncEvolution shouldn't be
dependent of something like this if we can avoid it. The result was that
users of libsyncevolution (the UI) must provide methods to read and
write passwords outside of the core configuration.
So where does that leave the syncevo-dbus-server? My original goal was
to let its clients as the final UI decide where to store passwords, but
Jussi correctly pointed out that a GTK app might very well run inside
KDE with a KDE keyring, so pushing the decision into the UI is no
solution.
In addition, when we want to run syncs automatically, then the
syncevo-dbus-server needs access to securely stored passwords in the
keyring. So the syncevo-dbus-server executable will depend on the GNOME
keyring. Whether it actually uses the keyring has to be configurable,
because in some situations (running as cron job) the keyring won't be
available. I suggest adding the following server configuration option:
# Controls password storage. Changing this setting does not
# move the passwords themselves, which has to be done manually.
#
# "config" - store passwords in the SyncEvolution config.ini files
# "GNOME" - GNOME keyring
# default: GNOME (if support was compiled into the binary)
keystore=GNOME
Yongsheng, do you think we should remove the --keyring command line
parameter in favor of this configuration parameter?
Network monitoring might be another tricky problem, but in contrast to
password storage, I think it was solved via a freedesktop.org D-Bus API
which works under both KDE and GNOME. We can depend on that on Linux.
Please correct me if I am wrong.
--
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.
12 years
[SyncEvolution] D-Bus API: network monitoring
by Patrick Ohly
Hello!
Is this API okay? It's in the "dbus-api" branch, please comment and/or
suggest further patches.
commit 35f555809d79dec0a6e012a2706a3b72c54bd563
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Sep 11 20:03:44 2009 +0200
D-Bus API: added support for monitoring presence of servers
The D-Bus server contains the transports which exchange messages
with a SyncML server. Therefore it should also implement the
network monitoring. The API is meant to also cover Bluetooth
peers where the transport might be available, but not the
specific device.
Because the D-Bus server cannot determine whether there is
anyone subscribed to the Presence signal, clients need to
attach to the server if they want it to keep sending that
signal instead of shutting down.
diff --git a/src/dbus/interfaces/syncevo-server-full.xml b/src/dbus/interfaces/syncevo-server-full.xml
index cc8c91f..9a3d132 100644
--- a/src/dbus/interfaces/syncevo-server-full.xml
+++ b/src/dbus/interfaces/syncevo-server-full.xml
@@ -33,6 +33,28 @@
</doc:para>
</doc:doc>
+ <method name="Attach">
+ <doc:doc>
+ <doc:description>
+ With no client attached, the server will shut down after a
+ certain period of inactivity. Attaching to the server
+ prevents that. Attaching is not necessary to invoke methods.
+ The main purpose is to keep the server running while clients
+ are around and listen for signals, in particular the
+ Presence signal.
+ </doc:description>
+ </doc:doc>
+ </method>
+
+ <method name="Detach">
+ <doc:doc>
+ <doc:description>
+ Detaches an attached client. A client which disconnects
+ from D-Bus is automatically detached from the server.
+ </doc:description>
+ </doc:doc>
+ </method>
+
<method name ="GetConfigs">
<doc:doc><doc:description>Get an array of all configured servers (or templates)</doc:description></doc:doc>
<arg type="b" name="template" direction="in">
@@ -65,6 +87,19 @@
</arg>
</method>
+ <method name="CheckPresence">
+ <doc:doc><doc:description>Checks whether a sync with a particular server can start.</doc:description></doc:doc>
+ <arg type="s" name="server" direction="in">
+ <doc:doc><doc:summary>server name</doc:summary></doc:doc>
+ </arg>
+ <arg type="s" name="status">
+ <doc:doc>
+ <doc:summary>
+ See Presence signal for details.
+ </doc:summary>
+ </doc:doc>
+ </method>
+
<method name="GetReports">
<doc:doc><doc:description>Get synchronization reports for a specific server</doc:description></doc:doc>
<arg type="s" name="server" direction="in">
@@ -231,5 +266,39 @@
</arg>
</signal>
+ <signal name="Presence">
+ <doc:doc>
+ <doc:description>
+ Indicates whether a server can be reached right now. This
+ signal can be used by GUIs to prevent starting a sync when
+ it is known to fail, for example because the network is
+ currently down.
+
+ At the moment, the SyncEvolution server can only monitor
+ network connectivity, which is a cheap local operation and
+ thus done unconditionally while the server runs (see
+ Attach()). Detecting the presence of non-HTTP-based peers
+ might be more costly. Additional APIs might be added to turn
+ that on only when needed. The CheckPresence() method will
+ always force a check.
+ </doc:description>
+ </doc:doc>
+ <arg type="s" name="server">
+ <doc:doc><doc:summary>name of the server configuration</doc:summary></doc:doc>
+ </arg>
+ <arg type="s" name="status">
+ <doc:doc>
+ <doc:summary>
+ "no transport" - the transport necessary to reach the server is not working.
+ "not present" - the server is known to be down or unreachable.
+ "" - the server might be usable. Syncs can still fail.
+ Other non-empty strings might be added in the future. They always
+ indicate a condition which prevents syncing.
+ </doc:summary>
+ </doc:doc>
+ </arg>
+
+ </signal>
+
</interface>
</node>
diff --git a/src/dbus/interfaces/syncevo-session-full.xml b/src/dbus/interfaces/syncevo-session-full.xml
index 729bf35..9e8445d 100644
--- a/src/dbus/interfaces/syncevo-session-full.xml
+++ b/src/dbus/interfaces/syncevo-session-full.xml
@@ -90,6 +90,16 @@
<doc:doc><doc:description>Detach from the session.</doc:description></doc:doc>
</method>
+ <method name="CheckPresence">
+ <doc:doc><doc:description>Checks whether a sync with the current server can start.</doc:description></doc:doc>
+ <arg type="s" name="status">
+ <doc:doc>
+ <doc:summary>
+ See org.syncevolution.Server Presence signal for details.
+ </doc:summary>
+ </doc:doc>
+ </method>
+
<method name="GetStatus">
<doc:doc><doc:description>Get session status. Individual source statuses are relevant and provided only when status is neither "queuing" nor "idle".</doc:description></doc:doc>
<arg type="s" name="status" direction="out">
12 years