Re: [SyncEvolution] SAN generating for obex transport]
Yes. Your last comment was that you were leaning towards a
comma-separated list of urls, wasn't it?
Yes, let's use the more compact version.
> > 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).
Do you mean we need a obex specific property, covers the Server Identifier and
the source alias; http specific property later and may possibly contains a real
SyncServerURL and something else.
Yes, I just think they are something similar.
Best Regards,
Congwu