2:56 a.m.
I think maybe I misunderstand Patrick.
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
This is a 'configure' option, not
command line arguments, right?
What I implement now is to do runtime checking - add checking for command line arguments.
So we don't give users privilege to decide whether to use sync daemon in the runtime?
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