9:10 a.m.
With SyncML Server/Obex client binding, we need to send a SAN package first
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().
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
engine.
There need another extention for the configuration too: we need both remote
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.
syncClientURL is something the current configuration missed and is more
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.
--
Regards,
Chen Congwu
Moblin China Development
10:07 a.m.
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
first
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
engine.
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
promptly.
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
really connects.
There need another extention for the configuration too: we need both
remote
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
more
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
use
"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.
10:57 a.m.
Ohly, Patrick wrote:
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.
Looks reasonable. So for a desktop with a SyncML server, I would create a
configuration named something like "MyServer" and with
"PeerIsClient=1".
Here "Peer" means the remote device, while the configuration is actually
about local server settings.
For a netbook with a SyncML Client, I would create a configuration named
"SyncWithMyServer" and with "PeerIsClient=0". Here "peer"
also means the
remote device while the configuration is actually about the remote device.
Ohly, Patrick wrote:
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
promptly.
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
really connects.
Probably the dbus server will use the same server configuration and a list of
syncClientURLs, send SAN to each peer and start the sync session with the first
received SAN response.
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?
Well, I'm starting to persuade me to use a list of URLs to not introduce so
many additional properties..
Best Regards,
Congwu
1:09 p.m.
On Tue, 2009-10-20 at 10:57 +0100, Chen, Congwu wrote:
Ohly, Patrick wrote:
>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.
Looks reasonable. So for a desktop with a SyncML server, I would create a
configuration named something like "MyServer" and with
"PeerIsClient=1".
Yes, each SyncML client needs his own peer configuration. Very much
relevant in this context is the redesign of the configuration layout
discussed earlier on the list, the one were I propose to keep one set of
source configurations and attached to it multiple peer configurations,
without duplicating the source configuration for each peer.
>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?
>
Well, I'm starting to persuade me to use a list of URLs to not introduce so
many additional properties..
That would be fine with me.
--
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.
2:39 p.m.
On Tue, 2009-10-20 at 09:10 +0100, Chen Congwu wrote:
There need another extention for the configuration too: we need both
remote
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.
I've thought a bit more about this. Previously we agreed to use syncURL
for a remote HTTP server (when the peer is a server) and for the local
sync URL (when we ourselves are the server). "clientURL" would be added
for peers which are clients.
This makes the interpretation of the syncURL property dependent on
another one (PeerIsClient). After thinking about this some more I find
this confusing and unnecessarily complex. I think we can simply redefine
"syncURL" as the property which lists the "method(s) to contact the
peer". This works for peers which are clients and servers.
So do we need another "syncServerURL" setting for a server? I have my
doubts about it. As Lukas pointed out, the externally visible way of
contacting our server is transport specific. In our design with
transport stubs, the configuration of those stubs determines the URL,
not the peer configuration inside SyncEvolution.
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.
--
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.
4587
days inactive
4593
days old
syncevolution@synevolution.org
4 comments
3 participants
participants (3)
-
Chen Congwu -
Chen, Congwu
-
Patrick Ohly