10:59 p.m.
http://bugs.meego.com/show_bug.cgi?id=2254
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |syncevolution-default-bugs@
| |meego.bugs
Component|SyncEvolution |SyncEvolution
Version|1.0 |unspecified
AssignedTo|patrick.ohly(a)intel.com |syncevolution-bugs(a)meego.bu
| |gs
Product|OS Middleware |SyncEvolution
Severity|normal |enhancement
--- Comment #1 from pohly <patrick.ohly(a)intel.com> 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.