12:41 p.m.
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
Yes, the way I'm implementing is what
Patrick says but with a difference by
using option '--dbus' or '-b'. I'll change it.
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.
I'd like to implement it in this way.
Cheers,
Yongsheng
> -----Original Message-----
> From: syncevolution-bounces(a)syncevolution.org
> [mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly
> Sent: Monday, March 22, 2010 12:34 AM
> To: David Bremner
> Cc: syncevolution(a)syncevolution.org
> Subject: Re: [SyncEvolution] syncevo-dbus-server and command line client
>
> 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.
>
>
> _______________________________________________
> SyncEvolution mailing list
> SyncEvolution(a)syncevolution.org
> http://lists.syncevolution.org/listinfo/syncevolution