Hi Patrick,
On Sep 23, 2009, at 17:34 , Patrick Ohly wrote:
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.
I guess the big plan (tm) was to have SyncML DM / OMA DM for remote
provisioning settings, which has IMHO a bootstrap scenario to get
started with a new device. However, DM was designed very much with
large organisation's needs for remote control and restriction in mind,
so might not have been a good fit for your plans either.
[...] 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.
looking for example at iSync, I guess that's what all the others do.
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?
I haven't dug through all the OMA DS proposals yet, and also haven't
really read the Bonjour specs so I don't know if there's anything
usable already underway. But if not, starting a proposal is worth a try.
Generally, I think one should look at SyncML like at any other Web/XML
based service, and treat actual sync as separated as possible from
service discovery. SyncML sync itself is well-defined, various
existing service discovery methods are as well. I assume generic and
open standard push signalling will (or has - I have no idea, need to
research) appear as well.
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.
My personal opinion is that the client should have as much control as
possible, which means all scheduled automatic sync, or sync-on-server-
in-reach should be client detected and client initiated. The only
exception is sync-on-new-data-from-the-cloud, i.e. push.
Even if the cloud is local - I think the scenario of local syncing
really while sitting in front of a desktop machine is something from
the past. When I'm sitting on the sofa with my Moblin Netbook, and I
want to sync my stuff with the PC somewhere in the house, I don't want
to go there and hit a button. Most likely, that PC will become a media
server hidden in a cupboard anyway, and all end user terminals will be
mobiles of different kinds, from phone up to laptop...
Lukas Zeller (l...@synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
