http://bugs.meego.com/show_bug.cgi?id=2254
pohly <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |syncevolution-default-bugs@ | |meego.bugs Component|SyncEvolution |SyncEvolution Version|1.0 |unspecified AssignedTo|[email protected] |[email protected] | |gs Product|OS Middleware |SyncEvolution Severity|normal |enhancement --- Comment #1 from pohly <[email protected]> 2010-05-18 05:59:44 PDT --- (In reply to comment #0) > Besides the "personal" covered by the HTTP http server UI submitted, there is > also a usecase for those having a small home server. In this scenario, it's > not > really easy to use the http server as of today. I agree, this could be simplified. My own thinking was to remove the need for separate D-Bus startup script and roll that into the syncevo-http-server.py itself, including starting of syncevo-dbus-server and setting env variables when installed in a non-standard location. > My own thoughts on this are that with two reasonable changes this should work > quite fine. > > The first is to allow the http server to run without Seahorse. Seahorse is > really not useful in this scenario, and adds a lot of dependencies including > an > accessible X display (even if it's not used). If the username/password are set inside the config.ini files, then the GNOME keyring should never be accessed. Is that failing for you? > For the headless case maybe just > validating the user's login password would be enough. Unfortunately there's no way for a user space program to access the password. Access to a plain text password is required by the SyncML protocol. Alternatively, someone could implement HTTP auth (bug #1349) and then disable password checking at the SyncML level. > The other fix is to allow the server to run from inetd. This would give > advantages w r t server load and http server stability (since it's just > restarted for each sync). This means that it should be able to use > stdin/stdout > instead of socket communications when given a command line option. That looks worthwhile, but the implementation is a bit more complex: the syncevo-http-server<->syncevo-dbus-server communication is not stateless. The syncevo-http-server must remain running throughout a SyncML session and handle all POST requests possibly related to it. A client which cuts the connection between messages would end up starting different instances of syncevo-http-server, if I'm not mistaken. -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
