Hello!
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:
1. http://bugs.meego.com/show_bug.cgi?id=10031 "needs to be
restarted after loss of connection"
2. http://bugs.meego.com/show_bug.cgi?id=1367 "nightly testing:
include SyncEvolution <-> SyncEvolution testing"
3. http://bugs.meego.com/show_bug.cgi?id=6369 "Error reporting in
HTTP server is sucky (Or: HTTP server ignores LogOutput dbus
signals)"
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
syncevo-http-server itself
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
syncevo-http-server.
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)
--start-syncevolution[=<path>]
sets up the right environment for
<path>/sbin/syncevo-dbus-server
and starts it explicitly, instead of depending on D-Bus
auto-activation;
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
syncevo-http-server script
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
