As usual, I'd like to write down some thoughts on future functionality
before actually implement it. This email is about syncevo-http-server,
the HTTP server which allows SyncML HTTP clients to synchronize with
SyncEvolution running as server.
There are some open issues to be solved:
"needs to be
restarted after loss of connection"
include SyncEvolution <-> SyncEvolution testing"
"Error reporting in
HTTP server is sucky (Or: HTTP server ignores LogOutput dbus
4. simplify startup (no issue filed)
The first one is still something that I haven't tried to reproduce. My
goal is to set up a test case first, automate it (second issue) and then
fix the problem.
Error reporting has been an issue, because users need to monitor the
output of syncevo-dbus-server and syncevo-http-server. The intention
here is to keep syncevo-dbus-server running in the background (as
before) and improve the output of syncevo-http-server:
1. catch the rather cryptic Twisted error messages
2. translate them into INFO/DEBUG/ERROR messages
3. show syncevo-dbus-server errors together with the messages from
Finally, the rather complex startup for the "SyncEvolution on headless
server" case (start D-Bus session, start syncevo-dbus-server +
syncevo-http-server) should be combined into one invocation of
This needs to be optional, because on a normal desktop,
syncevo-http-server should not start another D-Bus session (would
confuse Evolution Data Server).
So here are the new command line options that I intend to implement:
-d|--debug enables debug messages
-q|--quiet limits output to real error messages; ignored if -d is given
--start-dbus-session creates a new D-Bus session for communication with
syncevo-dbus-server and (inside that server) with other
D-Bus services like Evolution Data Server; should only
be used if it is guaranteed that the current user will
not have another session running, because these services
can get confused when started multiple times; without this
option, syncevo-http-server a) uses the session specified
in the environment or b) looks for a session of the current
user (depends on recent ConsoleKit and might not always work)
sets up the right environment for
and starts it explicitly, instead of depending on D-Bus
to be used when SyncEvolution is not installed at the location
it was compiled for (typically /usr); the <path> is optional,
if not given, then it'll be derived from the location of the
Does that make sense? Are there better names for these options?
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.