On Tue, 2009-10-20 at 10:57 +0100, Chen, Congwu wrote:
> 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".

Yes, each SyncML client needs his own peer configuration. Very much
relevant in this context is the redesign of the configuration layout
discussed earlier on the list, the one were I propose to keep one set of
source configurations and attached to it multiple peer configurations,
without duplicating the source configuration for each peer.

> >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..

That would be fine with me.

-- 
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

Reply via email to