Ohly, Patrick wrote: >I would simplify this option to just "PeerIsClient = 0/1", with default >"off". There's more than just the generation of the SAN which depends on >knowing this. The local meta information handling also depends on it. Looks reasonable. So for a desktop with a SyncML server, I would create a configuration named something like "MyServer" and with "PeerIsClient=1". Here "Peer" means the remote device, while the configuration is actually about local server settings. For a netbook with a SyncML Client, I would create a configuration named "SyncWithMyServer" and with "PeerIsClient=0". Here "peer" also means the remote device while the configuration is actually about the remote device.
Ohly, Patrick wrote: >Agreed in principle. The question is: when do we create a session for >the expected incoming connect from the client? In the first step we can >and should probably do that right away and expect the client to reply >promptly. > >Later we might also end up with use cases (push) where we generate SANs >without getting a quick reply; for those cases it might become necessary >to send out the SAN and not set up any local state unless the client >really connects. Probably the dbus server will use the same server configuration and a list of syncClientURLs, send SAN to each peer and start the sync session with the first received SAN response. >What content would you use for SANPeerURL/clientURL/PeerIsClient? An >artificial URL like "obex+bluetooth://<mac>+<channel>"? >How would we handle multiple ways of contacting the same client? Comma >separated list of URLs or multiple properties under different names? > Well, I'm starting to persuade me to use a list of URLs to not introduce so many additional properties.. Best Regards, Congwu _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
