7:57 a.m.
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.
9:31 p.m.
On So, 2010-12-26 at 07:31 +0000, Giancarlo wrote:
Patrick Ohly <patrick.ohly@...> writes:
>
> Hello!
>
> As usual, I'd like to write down some thoughts on future functionality
> before actually implement it.
May I suggest also some way to have an encrypted channel, either through https
or ssh?
Right, forgot about those. ssh would require changes in SyncEvolution,
but would be doable. https probably has more advantages.
Additional option:
--server-certificate=<file> certificate used by the server to identify
itself (TODO: details about file content)
I'm not planning to support client certificate checking, at least not
initially.
--
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.
7:44 a.m.
Patrick Ohly <patrick.ohly@...> writes:
Hello!
As usual, I'd like to write down some thoughts on future functionality
before actually implement it.
How difficult would it be to have Obex over USB? It can be a lot faster if there
are many items to sync, and is possibly more secure (especially in crowded
environments such as apartment buildings).
Just a dream, perhaps, but it would be nice to have an option for
Lightning/Thunderbird/Seamonkey. It's a nice alternative for a lightweight
system where Evolution with Gnome dependencies is more than one wants.
Unfortunately, my coding skills are minimal so I can't help in that area, but
I'd be very willing to help with testing.
Irihapeti
8:01 a.m.
New subject: [SyncEvolution] OBEX over USB (was: Re: syncevo-http-server: planning of new functionality)
On So, 2010-12-26 at 20:44 +0000, Irihapeti wrote:
How difficult would it be to have Obex over USB?
I don't know. Definitely needs a developer who is interested in adding
such a feature.
--
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:23 p.m.
On Mi, 2010-12-22 at 20:57 +0000, Patrick Ohly wrote:
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)
Actually there is a issue for the last point:
http://bugs.meego.com/show_bug.cgi?id=10270
--
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.
8:23 p.m.
On Mi, 2010-12-22 at 20:57 +0000, Patrick Ohly wrote:
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)
[...]
> May I suggest also some way to have an encrypted channel,
either
through https
> or ssh?
Right, forgot about those. ssh would require changes in SyncEvolution,
but would be doable. https probably has more advantages.
All of these are resolved, except for automating the testing. It passes
when invoked manually, despite making the tests harder (additional
"connection lost" error scenario included).
Those interested in this should use the script from git, as mentioned
already in some other emails.
--
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.
4268
days inactive
4288
days old
syncevolution@synevolution.org
6 comments
3 participants
participants (3)
-
Giancarlo -
Irihapeti -
Patrick Ohly