> 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-boun...@syncevolution.org > [mailto:syncevolution-boun...@syncevolution.org] On Behalf Of Patrick Ohly > Sent: Monday, March 22, 2010 12:34 AM > To: David Bremner > Cc: syncevolution@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.o...@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@syncevolution.org > http://lists.syncevolution.org/listinfo/syncevolution _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
