9:14 a.m.
Hi,
This was something I've been meaning to ask, but keep forgetting: How am
I supposed to use defaultPeer configuration item?
This is what I'm trying (no non-default contexts or anything):
1. On UI startup: Call Server.GetConfig() onto get config value
{"","defaultPeer"}. I assume using "default" as
configuration/template
name would work.
2. When saving a configuration and setting it as default: Call
Session.SetConfig() for configuration <name> with {"",
"defaultPeer",
"<name>"} in it.
The problem is that defaultPeer seems to get saved in <name>/config.ini
instead of global config.ini. What am I doing wrong?
- Jussi
12:14 p.m.
On Tue, 2009-12-01 at 09:14 +0000, Jussi Kukkonen wrote:
Hi,
This was something I've been meaning to ask, but keep forgetting: How am
I supposed to use defaultPeer configuration item?
This is what I'm trying (no non-default contexts or anything):
1. On UI startup: Call Server.GetConfig() onto get config value
{"","defaultPeer"}. I assume using "default" as
configuration/template
name would work.
No. "default" is the name of a peer. If you don't have such a
configuration, the call with fail.
What you want is either "" (empty string) or "@default" (same thing,
spelled out explicitly) to select the default context in which peers are
configured. That way you get a config which contains all shared
properties, including "defaultPeer", without any of the peer-specific
properties.
2. When saving a configuration and setting it as default: Call
Session.SetConfig() for configuration <name> with {"",
"defaultPeer",
"<name>"} in it.
I assume that "<name>" refers to an old-style config with no shared
properties. Use "" or "@default" when saving and it'll end up in
~/.config/default/config.ini, as expected.
--
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.
12:34 p.m.
Patrick Ohly wrote:
> 1. On UI startup: Call Server.GetConfig() onto get config value
> {"","defaultPeer"}. I assume using "default" as
configuration/template
> name would work.
No. "default" is the name of a peer. If you don't have such a
configuration, the call with fail.
What you want is either "" (empty string) or "@default" (same thing,
spelled out explicitly) to select the default context in which peers are
configured. That way you get a config which contains all shared
properties, including "defaultPeer", without any of the peer-specific
properties.
This is what I tried first and failed, but I tried again and see that it
does work with template=False.
> 2. When saving a configuration and setting it as default: Call
> Session.SetConfig() for configuration <name> with {"",
"defaultPeer",
> "<name>"} in it.
I assume that "<name>" refers to an old-style config with no shared
properties. Use "" or "@default" when saving and it'll end up in
~/.config/default/config.ini, as expected.
Ah, ok. I'll add another call then.
Thanks.
- Jussi
5:06 p.m.
On Tue, 2009-12-01 at 12:34 +0000, Jussi Kukkonen wrote:
Patrick Ohly wrote:
>> 1. On UI startup: Call Server.GetConfig() onto get config value
>> {"","defaultPeer"}. I assume using "default" as
configuration/template
>> name would work.
>
> No. "default" is the name of a peer. If you don't have such a
> configuration, the call with fail.
>
> What you want is either "" (empty string) or "@default" (same
thing,
> spelled out explicitly) to select the default context in which peers are
> configured. That way you get a config which contains all shared
> properties, including "defaultPeer", without any of the peer-specific
> properties.
This is what I tried first and failed, but I tried again and see that it
does work with template=False.
When checking this I found indeed a command line bug, which had the
effect that
syncevolution --configure --template scheduleworld foobarxxx
overwrotes the shared "defaultPeer" property because it wasn't part of
the template. This only happened because of an unnecessary optimization
which didn't read the context if it didn't exist, ignoring the fact that
the global property might still be set in that case.
But I can't reproduce it in the latest source of the
syncevo-dbus-server. The "server-config" branch contains the command
line fix and the new test-dbus.py TestMultipleConfigs.testSharedTemplate
test.
The test gets the defaultPeer that was set earlier when reading the
"scheduleworld" template:
method call sender=:1.1680 -> dest=:1.1681
path=/org/syncevolution/Server; interface=org.syncevolution.S
erver; member=GetConfig
string "scheduleworld"
boolean true
method return sender=:1.1681 -> dest=:1.1680 reply_serial=60
array [
dict entry(
string ""
array [
...
dict entry(
string "defaultPeer"
string "foobar_peer"
)
...
>> 2. When saving a configuration and setting it as default:
Call
>> Session.SetConfig() for configuration <name> with {"",
"defaultPeer",
>> "<name>"} in it.
>
> I assume that "<name>" refers to an old-style config with no shared
> properties. Use "" or "@default" when saving and it'll end
up in
> ~/.config/default/config.ini, as expected.
Ah, ok. I'll add another call then.
Not necessary, as discussed with Jussi via chat:
commit 431a576808e776610f8e5607d1c364a6cd4d60df
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Tue Dec 1 17:19:50 2009 +0100
defaultPeer: also shared when using legacy configs (MB #8334)
This patch allows a user to read and write the single "defaultPeer"
property in ~/.config/syncevolution/config.ini even when selecting
a peer which has a legacy config in ~/.config/syncevolution/<name>.
This is more convenient and ensures that the sync-UI works correctly
even in those cases where the legacy config cannot (or has not) been
migrated.
It works by adding multiplexing of properties to the HTTP_SERVER case
and then using a separate global config node.
Really, really old configs in .sync4j/evolution do not share the
defaultPeer property, but I think this is acceptable.
--
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.
4684
days inactive
4684
days old
syncevolution@synevolution.org
3 comments
2 participants
participants (2)
-
Jussi Kukkonen -
Patrick Ohly