7:11 p.m.
On Thu, 2009-11-05 at 01:42 +0000, Chen Congwu wrote:
>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?
The server stub which accepts the connection from the client needs that
piece of information. The SyncEvolution server itself doesn't need to
know its own syncURL.
For HTTP: currently the sync URL is a command line parameter of the
syncevo-http-server.py script.
For OBEX: MAC address is determined by the hardware, channel is assigned
by obexd.
I thing configuration has two types: configuration for a remote peer
and
configuration for myself.
Will their be another tag to differenciate this?
syncURL would always be for the remote peer.
> 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?
Yes. Your last comment was that you were leaning towards a
comma-separated list of urls, wasn't it?
So for a server that can be contacted both via OBEX and via HTTP, the
syncURL property would be:
syncURL = http://my.machine:8080/syncevolution, obex+bluetooth://00:0A:94:03:EB:E5+16
This is just a proposal. The exact format would have to be defined in
more detail.
So why do we handle "syncServerURL" and
"syncURL"
differently?
I don't think we need syncServerURL.
> 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?
Because the connection is established differently? In OBEX SyncEvolution
server -> client, the connection is created from inside SyncEvolution
and kept open for the whole duration of the session. In HTTP
SyncEvolution server -> client, different connections are needed (one to
send the SAN, one from client to server) and at least one other
component is needed (the HTTP listening stub).
--
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.