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
So this option is used in the runtime command line arguments.
I summarize up below behaviors:
If the option is explicitly set by user with value 'yes', then if the daemon is
compiled, try to use it. Otherwise, report an error.
If the option is explicitly set by user with value 'no', run command line in the
process without the daemon.
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 command line in the process without the
daemon.
Cheers,
Yongsheng
-----Original Message-----
From: Ohly, Patrick
Sent: Monday, March 22, 2010 3:21 PM
To: Zhu, Yongsheng
Cc: David Bremner; syncevolution(a)syncevolution.org
Subject: RE: [SyncEvolution] syncevo-dbus-server and command line client
On Mon, 2010-03-22 at 01:41 +0000, Zhu, Yongsheng wrote:
> > 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.
"dbus" is an implementation detail that users don't need to know about.
Hopefully they'll understand the concept of a daemon.
> > 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.
Okay. Answering your other email, the option above was meant to be a
runtime check, not a configure options.
--
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.