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
