Hello!
In #5188 ("Outgoing obex connection for SyncEvolution") Congwu and I
touched on some configuration related aspects. In particular we talked
about how to specify multiple ways of contacting a peer. We came to the
following conclusion:
1. add more peer settings like syncURL, using different names for
each possible transport
2. have one property which chooses the transport which is to be
used; by default it should be unset, which means that
SyncEvolution must pick a transport automatically (mostly based
on availability)
There's one problem with that: how does the GUI create such a
configuration correctly when it only knows that "Bluetooth device with
MAC address xyz is available for sync"? There might be a peer
configuration for this device already, using USB as transport. But
because the only common element between the two peers (the SyncML Device
ID) isn't available for Bluetooth at this point, the existing peer
configuration cannot be identified automatically.
Do we rely on the user to add the Bluetooth transport to the right
existing configuration? If he gets that wrong, he will end up with two
different local sets of meta data (source/addressbook/.other.ini), which
will break syncs when switching back and forth between the two
transports.
I think we should design our new configuration layout so that it is
tolerant of this. This means that the location of the .other.ini files
can only be determined once the peer's Device ID is known (internal
backend API change).
In #5188 I mentioned this idea (I said .internal.ini there, but I really
meant .other.ini, the node which is used for change tracking):
.config/syncevolution/default/.devices/<device ID>/
.other.ini
sources/addressbook/
.other.ini
We don't need .other.ini for the device. Placing the
per-source .other.ini in a place which is different from what we do now
is problematic for the backwards compatibility mode, besides making the
simple case (single-transport peers) more complex.
Therefore I suggest to keep the .other.ini in the peer/*/sources/*
directories, with one minor twist: when we learn about the Device ID of
a peer, we check which of the currently configured peers has the same ID
and .other.ini files. If we find one, we use that sources directory for
the .other.ini.
This creates another special case for removing a peer configuration: if
another peer has the same Device ID and sources, we must move
the .other.ini files to that peer, because they are still needed.
--
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
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
