Re: [SyncEvolution] SAN generating for obex transport]
On Wed, 04 Nov 2009, Ohly, Patrick wrote:
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.
I agree, this is
more clear.
For a server contacting clients (peer), the syncURL is the methods to contact
the client.
For a server contacted by clients, how do you define the syncURL?
I thing configuration has two types: configuration for a remote peer and
configuration for myself.
Will their be another tag to differenciate this?
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.
I think "syncURL" is
also transport specific, a remote peer can have syncURL
per transport, do you argree? So why do we handle "syncServerURL" and
"syncURL"
differently?
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.
Again, why do we handle HTTP and OBEX differently?
--
Regards,
Chen Congwu
Moblin China Development