On Tue, 2009-10-20 at 09:10 +0100, Chen Congwu wrote:
With SyncML Server/Obex client binding, we need to send a SAN package
before doing actual sync session, my suggestion is:
Add ServerAlertSync = 1 in the configuration and if it is set, SyncContext
should first call SendSan() before going to doSync().
I would simplify this option to just "PeerIsClient = 0/1", with default
"off". There's more than just the generation of the SAN which depends on
knowing this. The local meta information handling also depends on it.
This setting must not be changed after the initial sync. If the roles
get reversed later, a slow sync must be forced.
SyncContext::SendSan() will read configuration from server config,
generate the San package, send it with the transport agent and wait for a
reply. The reply will be treated as the first package feed to synthesis
Agreed in principle. The question is: when do we create a session for
the expected incoming connect from the client? In the first step we can
and should probably do that right away and expect the client to reply
Later we might also end up with use cases (push) where we generate SANs
without getting a quick reply; for those cases it might become necessary
to send out the SAN and not set up any local state unless the client
There need another extention for the configuration too: we need both
peer address(used to create the transport, call it syncClientURL) and server
syncURL (used to tell the client as part of the SAN, call it syncServerURL).
The existing syncURL property is more appropriate for syncServerURL.
Are you suggesting that we rename syncURL to syncServerURL? This changes
our user API (command line), so I'd prefer to keep the name and just
change the documentation.
Note that for Bluetooth there isn't really any URL for the server. Lukas
said that existing implementations don't even put something unique into
the SAN, just a fixed string. We need to emulate that behavior if we
want to be compatible with phones. An unsolved problem in this context
is the naming of our local data sources, which also must match what the
peers are expecting.
syncClientURL is something the current configuration missed and is
appropriate to be discoverd dynamically (via Bluetooth service discovery). I
suggest add "SANPeerURL" property: the property should be set manually now and
be set on the fly automatically later via some service discovery magic.
User's won't know and don't have to know what "SAN" is. I suggest to
"clientURL", because it is only relevant when "PeerIsClient = 1". We
might even use the deviceId and not introduce any new property: when
PeerIsClient, the server doesn't use the deviceId setting.
What content would you use for SANPeerURL/clientURL/PeerIsClient? An
artificial URL like "obex+bluetooth://<mac>+<channel>"?
How would we handle multiple ways of contacting the same client? Comma
separated list of URLs or multiple properties under different names?
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.