11:30 a.m.
Hi all,
Just wondered if there was any plan to extend the sync-gui interface to allow for a more
granular sync frequency (i.e. more than daily)?
I'm using on a nokia n900 and I'm thinking that it would ideallyt be good to have
something linked to dbus signals to syncronise a specific time period after the last
calendar update. Sort of delayed realtim e syncing. Only mention it because I'm
looking at a wrapper to do this.
Matt
12:46 p.m.
Am 15.03.2010 12:30, schrieb rustonm2005(a)yahoo.co.uk:
Hi all,
Just wondered if there was any plan to extend the sync-gui interface to
allow for a more granular sync frequency (i.e. more than daily)?
This would be nice but you also can use additional tools until it happens.
I'm using on a nokia n900 and I'm thinking that it would
ideallyt be
good to have something linked to dbus signals to syncronise a specific
time period after the last calendar update. Sort of delayed realtim e
syncing. Only mention it because I'm looking at a wrapper to do this.
I assume you can use a tool called alarmed for this job. More
information here:
http://maemo.org/packages/view/alarmed/
This tool can used with the xterm command of your choice and is able to
run the command every hour or minute. It also provides the ability to
To run syncevolution from xterm use:
syncevolution <name of your syncml-service e.g. 'scheduleworld'>
HTH, Uwe
--
Uwe Kaminski
http://internettabletblog.de
1:31 p.m.
On Mo, 2010-03-15 at 11:30 +0000, rustonm2005(a)yahoo.co.uk wrote:
Just wondered if there was any plan to extend the sync-gui interface
to allow for a more granular sync frequency (i.e. more than daily)?
I assume you mean the Maemo GUI?
Ove, are you subscribed to this list?
I'm using on a nokia n900 and I'm thinking that it would
ideallyt be
good to have something linked to dbus signals to syncronise a specific
time period after the last calendar update. Sort of delayed realtim e
syncing. Only mention it because I'm looking at a wrapper to do this.
We already implemented regular syncs in the core SyncEvolution, much
like Ove has done for the Maemo GUI (apparently - haven't seen it
myself) and Frederik did on the Genesis GUI. Sync frequency is
configurable there. This depends on running the syncevo-dbus-server,
something that Ove probably doesn't do yet in the Maemo package.
A more intelligent automatic syncing based on locally detected changes
and server notifications is planned for a release after 1.0.
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 ;-}
--
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.
3:46 p.m.
Patrick Ohly skrev:
On Mo, 2010-03-15 at 11:30 +0000, rustonm2005(a)yahoo.co.uk wrote:
> Just wondered if there was any plan to extend the sync-gui interface
> to allow for a more granular sync frequency (i.e. more than daily)?
I assume you mean the Maemo GUI?
Ove, are you subscribed to this list?
Sure... I thought I had already answered posts there before (that I
wasn't already Cc-ed on)...
> I'm using on a nokia n900 and I'm thinking that it would
ideallyt be
> good to have something linked to dbus signals to syncronise a specific
> time period after the last calendar update. Sort of delayed realtim e
> syncing. Only mention it because I'm looking at a wrapper to do this.
We already implemented regular syncs in the core SyncEvolution, much
like Ove has done for the Maemo GUI (apparently - haven't seen it
myself) and Frederik did on the Genesis GUI. Sync frequency is
configurable there. This depends on running the syncevo-dbus-server,
something that Ove probably doesn't do yet in the Maemo package.
Right, they're still based on 0.9. I'm not aware of any immediate need
for switching over to the 1.0 codebase. To do period syncs, the Maemo
frontend just hooks into alarmd, Nokia's crond-on-steroids thing.
In fact, running off syncevo-dbus-server would currently be a
disadvantage on a device such as the N900. The Maemo frontend
communicates with the N900's Internet Connectivity Daemon, which means:
1) If invoked from alarmd, the frontend asks ICD for an automatic (i.e.,
not user initiated) connection. If the device is not already connected,
the device's system policy will then take effect; if the device's policy
is to automatically connect to the nearest network (and there's one
nearby), the N900 will do so (and then notify the frontend when the
connection is up). If there's no available WLAN and the system settings
forbid automatic connection to GPRS/3G, then ICD will reject the
connection request, and the frontend will abort. (The user may sync
manually later by going into the GUI.)
2) ICD also maintains proxy settings for each configured network. Hence,
when roaming between different WLANs (and 3G), proxy settings may
change. After the ICD has notified the frontend that the connection is
up, the frontend then asks ICD for the current proxy settings, and if
any, provides them on the syncevolution command line using
--sync-property. The sync then starts.
3) After the sync, the connection is released. If nobody else was using
the connection, the device may then disconnect from the Internet again
at its leisure, saving power.
4) Also, alarmd hooks into the N900's power management system. The
alarmd is capable of waking the N900 from deep sleep, it can even turn
the device on at a preset time if powered off (although I don't use this
feature, of course). I'm not sure whether the N900 could enter deep
sleep if syncevo-dbus-server was running in the background, perhaps it
could, but in any case, using alarmd I *know* that none of the user's
precious battery power (or similarly precious RAM) is wasted in between
syncs. (Of course, once alarmd starts the frontend, some extra CPU
cycles may be spent running Python and stuff, but that's at least better
than any potential invisible battery drain between syncs, IMO.)
Perhaps it would be possible to patch in the ICD interface into
syncevolution so that its dbus-server thing could handle it without
needing the frontend, but it'd probably not be trivial, and I won't have
time to do anything like that anytime soon. So for now, on the N900, the
Maemo frontend's autosync is functionally superior to syncevolution's
own, and probably will be for a while.
The only complaint people seem to have about the frontend is that the
Maemo GUI doesn't allow anything but daily sync, but that's only a
problem with the user interface, not with the codebase. And the server
features etc of 1.0 is probably redundant on the N900. So I just haven't
seen the need for trying to port 1.0 at this time.
If people really want the Maemo GUI to support other sync periods than
daily, they should feel free to send me patches. I only need a daily
sync myself, so I might not get around to do it. And besides, I'm not
sure what a more flexible GUI should look like, at least without making
it much messier. For a patch, you only need to add the configuration
GUI, I can probably implement the alarmd magic (yes, the alarmd
interface is confusing and poorly documented). And this GUI change
would, of course, be needed regardless of whether the clock it
controlled was named syncevo-dbus-server or alarmd...
4:02 p.m.
On Wed, 2010-03-17 at 16:46 +0100, ovek(a)arcticnet.no wrote:
Right, they're still based on 0.9. I'm not aware of any
immediate need
for switching over to the 1.0 codebase.
Is there an easy way to test 1.0 on N900 to see if it can sync with
OGW ? That's kind of a blocker for me.
Xav
3:58 a.m.
Xavier Bestel skrev:
On Wed, 2010-03-17 at 16:46 +0100, ovek(a)arcticnet.no wrote:
> Right, they're still based on 0.9. I'm not aware of any immediate need
> for switching over to the 1.0 codebase.
Is there an easy way to test 1.0 on N900 to see if it can sync with
OGW ? That's kind of a blocker for me.
I've made a build of it and put it up at
http://people.debian.org/~ovek/experimental/
That is not an apt repository, so you'll need to download and install
the deb manually. It also likely will not integrate well with the
current GUI. I think syncevolution 1.0 may have a different config
layout. But if you really want to try it...
7:38 a.m.
On Wed, 2010-03-17 at 15:46 +0000, ovek(a)arcticnet.no wrote:
Patrick Ohly skrev:
>> I'm using on a nokia n900 and I'm thinking that it would ideallyt be
>> good to have something linked to dbus signals to syncronise a specific
>> time period after the last calendar update. Sort of delayed realtim e
>> syncing. Only mention it because I'm looking at a wrapper to do this.
>
> We already implemented regular syncs in the core SyncEvolution, much
> like Ove has done for the Maemo GUI (apparently - haven't seen it
> myself) and Frederik did on the Genesis GUI. Sync frequency is
> configurable there. This depends on running the syncevo-dbus-server,
> something that Ove probably doesn't do yet in the Maemo package.
Right, they're still based on 0.9. I'm not aware of any immediate need
for switching over to the 1.0 codebase.
It makes sense to stick to the stable version; we released 0.9.2 exactly
so that users didn't have to updated to a beta to get some of the fixes
and improvements.
However, there are improvements also for the HTTP client mode. At least
one addresses a problem that a Maemo user had: automatic backups consume
less disk space and inodes compared to 0.9.2.
To do period syncs, the Maemo
frontend just hooks into alarmd, Nokia's crond-on-steroids thing.
In fact, running off syncevo-dbus-server would currently be a
disadvantage on a device such as the N900.
Agreed. The current implementation doesn't take advantage of N900
platform specific features. Thanks for your detailed explanation. Long
term we definitely have to incorporate the same features in the core
SyncEvolution, using whatever services will be provided by MeeGo. It
will be interesting to see whether Nokia contributes the Internet
Connectivity Daemon to MeeGo. I'll ping some people...
--
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.
9:52 a.m.
New subject: [SyncEvolution] Open Groupware (was: Re: sync-gui auto sync frequency)
On Thu, 2010-03-18 at 03:58 +0000, Ove Kaaven wrote:
Xavier Bestel skrev:
> On Wed, 2010-03-17 at 16:46 +0100, ovek(a)arcticnet.no wrote:
>> Right, they're still based on 0.9. I'm not aware of any immediate need
>> for switching over to the 1.0 codebase.
>
> Is there an easy way to test 1.0 on N900 to see if it can sync with
> OGW ? That's kind of a blocker for me.
I've made a build of it and put it up at
http://people.debian.org/~ovek/experimental/
That is not an apt repository, so you'll need to download and install
the deb manually. It also likely will not integrate well with the
current GUI. I think syncevolution 1.0 may have a different config
layout.
The config layout is different, but it'll read and write to the old one
just fine. Does the GUI write configs directly instead of invoking the
command line? In the latter case it would end up creating the new layout
if the config did not exist yet in the old layout.
Xavier, about Open Groupware: I don't think there were any relevant
changes compared to 0.9.2. We added a few more knobs that can be turned,
but haven't done any specific testing with OGW.
Your best bet to get it working is to test it, then provide bug reports
to us via bugzilla.moblin.org. If we cannot determine the root cause or
it is something on the server side, then you'll have to bring it up with
OGW developers. We don't have the time right to do more testing
ourselves right now and we don't know anyone working on OGW.
--
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.
10 a.m.
New subject: [SyncEvolution] Open Groupware
Patrick Ohly wrote:
The config layout is different, but it'll read and write to the
old one
just fine. Does the GUI write configs directly instead of invoking the
command line? In the latter case it would end up creating the new layout
if the config did not exist yet in the old layout.
It uses the command line, but makes some assumptions, at least in the
service edit dialog.
1:39 p.m.
New subject: [SyncEvolution] syncevo-dbus-server and command line client
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?
I'm curious because right now the ("official") Debian packages split
into two binary packages, one containing the command line client,
another sync-ui+dbus. I think this is worthwhile because the
dependencies of sync-ui are a bit heavy.
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.
All the best,
David
4:34 p.m.
New subject: [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.
1:41 a.m.
New subject: [SyncEvolution] syncevo-dbus-server and command line client
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
2:56 a.m.
New subject: [SyncEvolution] syncevo-dbus-server and command line client
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
7:20 a.m.
New subject: [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.
7:29 a.m.
New subject: [SyncEvolution] syncevo-dbus-server and command line client
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.
9:15 a.m.
New subject: [SyncEvolution] syncevo-dbus-server and command line client
On Mon, 2010-03-22 at 07:29 +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
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.
Nit-picking: if no support for D-Bus is compiled *into the command
line*, report one error ("support for --use-daemon not available in this
binary"?). That may or may not be the same as having compiled the
daemon. If the daemon fails to start, report that error.
Currently we only have --enable-dbus-service, which enables *building*
syncevo-dbus-server. Should we enable support for *using* it with that
same option? I think I prefer to keep it simple and use just one option.
--
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.
9:45 a.m.
New subject: [SyncEvolution] syncevo-dbus-server and command line client
Nit-picking: if no support for D-Bus is compiled *into the command
line*, report one error ("support for --use-daemon not available in this
binary"?). That may or may not be the same as having compiled the
daemon. If the daemon fails to start, report that error.
Yes, you are right. Because command line and dbus server can be compiled
separately.
Currently we only have --enable-dbus-service, which enables
*building*
syncevo-dbus-server. Should we enable support for *using* it with that
same option? I think I prefer to keep it simple and use just one option.
You mean use '--enable-dbus-service [yes/no]' in the command line option?
Yes,
I think it's a good suggestion. It means 'enabling dbus service usage in the
command
line'.
Cheers,
Yongsheng
> -----Original Message-----
> From: Ohly, Patrick
> Sent: Monday, March 22, 2010 5:15 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 07:29 +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
> > 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.
>
Nit-picking: if no support for D-Bus is compiled *into the command
line*, report one error ("support for --use-daemon not available in this
binary"?). That may or may not be the same as having compiled the
daemon. If the daemon fails to start, report that error.
>
Currently we only have --enable-dbus-service, which enables
*building*
syncevo-dbus-server. Should we enable support for *using* it with that
same option? I think I prefer to keep it simple and use just one option.
>
> --
> 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.
>
10:12 a.m.
New subject: [SyncEvolution] syncevo-dbus-server and command line client
On Mon, 2010-03-22 at 09:45 +0000, Zhu, Yongsheng wrote:
> Currently we only have --enable-dbus-service, which enables
*building*
> syncevo-dbus-server. Should we enable support for *using* it with that
> same option? I think I prefer to keep it simple and use just one option.
You mean use '--enable-dbus-service [yes/no]' in the command line option? Yes,
I think it's a good suggestion. It means 'enabling dbus service usage in the
command
line'.
No, I think we should expand its scope to
--enable-dbus-service enables building syncevo-dbus-server and all
related features (D-Bus wrapper library,
command line usage of server, ...)
--
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.
4485
days inactive
4492
days old
syncevolution@synevolution.org
17 comments
8 participants
participants (8)
-
David Bremner -
Ove Kaaven -
ovek＠arcticnet.no
-
Patrick Ohly -
rustonm2005＠yahoo.co.uk -
Uwe Kaminski -
Xavier Bestel -
Zhu, Yongsheng