Re: [SyncEvolution] syncevo-http-server: planning of new functionality
On Mi, 2010-12-22 at 20:57 +, 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] syncevo-http-server: planning of new functionality
On Mi, 2010-12-22 at 20:57 +, 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] syncevo-http-server: planning of new functionality
On So, 2010-12-26 at 07:31 +, Giancarlo wrote: Patrick Ohly patrick.o...@... 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. ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] syncevo-http-server: planning of new functionality
Patrick Ohly patrick.o...@... 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 ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
Re: [SyncEvolution] syncevo-http-server: planning of new functionality
Patrick Ohly patrick.o...@... 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? Best regards and best wishes giancarlo ___ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
[SyncEvolution] syncevo-http-server: planning of new functionality
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|--debugenables debug messages -q|--quietlimits 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 SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
