Re: [SyncEvolution] SAN generating for obex transport]

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