On Sun, 2010-03-21 at 13:39 +0000, David Bremner wrote:
On Mon, 15 Mar 2010 14:31:49 +0100, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
>
> Ove, Frederik, you can continue to use the command line in your
> frontends even when the syncevo-dbus-server is active. We intend to
> change the command line so that it uses the syncevo-dbus-server
> transparently in the final 1.0. Of course, rewriting the frontends to
> use the D-Bus API would be nicer ;-}
>
Does this mean that the syncevolution command line client will depend on
the syncevo-dbus-server (in the sense that it will not function
correctly without it) or just cooperate/offer-more functionality if the
dbus server is available?
It will cooperate. The current model where the command line loads
libsyncevolution and does all operations (config, sync) in a single
process will still be possible. We haven't quite decides yet what the
default will be.
Your comment about syncevo-dbus-server being compiled, but not installed
implies that the default should better do a runtime check, something
like:
--use-daemon[=yes/no] run operations in cooperation with the
background sync daemon; enabled by default if
it is installed
If the option is not given, the command line should try to start the
daemon. If that works, use it. If not, fall back to running the sync in
the process. The alternative is to check whether the syncevo-dbus-server
is installed in the location where it should be. The advantage of that
is that failing to start an installed daemon can be reported as error.
The disadvantage is that a daemon compiled differently might not be
found.
The more I think about it, the second one is perhaps the better one.
It's simpler to implement and has obvious failure behavior.
I have in an experimental branch also split off syncevo-dbus-server
into
its own package, so it would not be much trouble to be more flexible
about what combinations of cli/gtk-client/dbus-server are
installable. We can make sure the default is sensible by using
recommends.
I started thinking about this because the discussion of
syncevo-http-server.py, which I can imagine wanting to have installed
without sync-ui, and which is really a pretty thin wrapper on the dbus
server.
I think splitting the daemon off makes sense.
--
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.