On Mon, 2009-09-21 at 16:31 +0100, Lukas Zeller wrote: > I also attached a PDF (Synthesis_SyncML_SAN_implementation_notes.pdf) > which documents the way we have implemented SAN in the Synthesis PDA > clients (Winmobile and PalmOS). It might answer some of the questions > already.
Yes, it does, at least for the HTTP server case. Thanks! > On Sep 21, 2009, at 15:09 , Patrick Ohly wrote: > > > On Thu, 2009-07-30 at 18:15 +0200, Patrick Ohly wrote: > > [...] That of course simplifies the generation of a SAN package on > > the server, > > but it raises the question how the client can synchronize against the > > server without some additional configuration on the client. > > It can't. Devices which support local BT sync via SyncML have a pre- > installed or hardwired profile called something like "PC-Suite" (Nokia > for example) which contains the configuration. What a missed opportunity :-( I guess I was expecting too much from automatic syncing via Bluetooth/OBEX/SAN. > > One more question: the SAN header contains the server ID, just as in > > the > > DevInf. This is the only way how a client can identify the > > configuration > > which might have been prepared locally for that server. But when > > preparing that configuration the client doesn't know the server ID > > yet. > > Correct again :-) But for a local obex connection, there is no real > server URL anyway. So devices use a fixed string for that ID that does > not identify the server instance, but the server kind (Nokia again: > "PC Suite"). This is sufficient as BT pairing or local cable > connection makes sure the user actually wants this server instance to > talk to this particular device. So multiple hosts will use the same string. That's bad for us, because we would like to uniquely identify the peer before running a sync. Without that, the user would be forced to use the same configuration for all hosts (can't sync private calendar with home PC and work calendar with work PC). We also have a SyncEvolution internal problem of locating additional meta information about the peer before the sync starts. I fear that these disadvantages are significant enough so that we have to compare meta information (like Bluetooth MAC address) to identify the peer in advance. > IMHO, SAN is doomed, and I have little hope it will ever make real > sense in today's or even future cloud sync. Same for OBEX over BT > sync. Agreed. We have to support it for Bluetooth, but really should think about alternatives. > But I also would like to start thinking about what could replace it. I > think WLAN with Bonjour (and then plain HTTP based SyncML) can do most > of what SAN was intended for - local sync, autosyncing when reaching a > home network etc. Do you know whether any kind of working group or set developers is thinking about this kind of problem? Should we start a proposal? > IMHO having no push for local sync is not a problem at all - I always > perceived it as wrong when the PC tried to start to sync my device and > not the other way around. The SyncML OBEX binding allows client initiated SyncML sessions. It's just a matter of using it. Client and server of course also need to agree about who takes the initiative when automatic syncs are supposed to happen without the user hitting a button. -- 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. _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
