On Tue, 2009-10-20 at 09:10 +0100, Chen Congwu wrote: > There need another extention for the configuration too: we need both remote > peer address(used to create the transport, call it syncClientURL) and server > syncURL (used to tell the client as part of the SAN, call it syncServerURL). > The existing syncURL property is more appropriate for syncServerURL.
I've thought a bit more about this. Previously we agreed to use syncURL for a remote HTTP server (when the peer is a server) and for the local sync URL (when we ourselves are the server). "clientURL" would be added for peers which are clients. This makes the interpretation of the syncURL property dependent on another one (PeerIsClient). After thinking about this some more I find this confusing and unnecessarily complex. I think we can simply redefine "syncURL" as the property which lists the "method(s) to contact the peer". This works for peers which are clients and servers. So do we need another "syncServerURL" setting for a server? I have my doubts about it. As Lukas pointed out, the externally visible way of contacting our server is transport specific. In our design with transport stubs, the configuration of those stubs determines the URL, not the peer configuration inside SyncEvolution. Let's look at specific transports. For OBEX, we need to set the right server identifier, because some phones expect certain strings like "PC Suite". This is a new per-peer configuration option. Along the same line, we also need "aliases" for source names. What we call "addressbook" locally might only be recognized as "./Contacts" by a peer. For HTTP, the SAN can only be sent by a transport-specific mechanism which doesn't exist at the moment. Once we create it, we can think about how the HTTP server URL can be fed into it. We don't have to worry about it now. -- 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
