6:05 p.m.
Hello Patrick
If the syncevo-dbus-server is supposed to work as a syncML server, the dus api
Server.connect need peer.config to be set explictly to select the appropriate
configuration.
I noticed the http server now uses the request url path to identify this. How
can this be handled in obexd? The only possible information Obexd can get
without looking into the message is the peer's Mac address, but this property
seems not appropriate for configuration identification (The same device can
have multiple remote configuraitons).
I am asking this because I am using Obexd+SyncEvolution Server <--> Obex
Client+client-test for the obex transport test. It looks not easy for the obexd
to set the peer.config properly without looking into the message; therefore
either it always stick to a default configuration or the server need some other
mechanism to detect the configuraitons itself.
Also, the documentation seems have not updated to include peer.config.
--
Regards,
Chen Congwu
Moblin China Development
6:44 p.m.
On Thu, 2009-11-05 at 07:05 +0000, Chen, Congwu wrote:
If the syncevo-dbus-server is supposed to work as a syncML server,
the dus api
Server.connect need peer.config to be set explictly to select the appropriate
configuration.
This is a short-term workaround. The final solution will be that the
server analyzes the first SyncML message, extracts the device ID,
searches for the corresponding configuration, then runs a sync session
with that configuration.
From:
http://bugzilla.moblin.org/show_bug.cgi?id=7710
- we should delay picking a peer configuration until we really
know the peer's device ID; currently we only check that the
pre-chosen peer configuration matches
I noticed the http server now uses the request url path to identify
this. How
can this be handled in obexd? The only possible information Obexd can get
without looking into the message is the peer's Mac address, but this property
seems not appropriate for configuration identification (The same device can
have multiple remote configuraitons).
We still might have to do some matching of MAC address against
configuration on the client when it receives a SAN message. Depending on
what server created that message, the server ID in that message might
not be unique. When SyncEvolution talks to SyncEvolution we can (and
should) avoid that ambiguity and put the server's deviceID into the SAN
message.
I am asking this because I am using Obexd+SyncEvolution Server
<--> Obex
Client+client-test for the obex transport test. It looks not easy for the obexd
to set the peer.config properly without looking into the message; therefore
either it always stick to a default configuration or the server need some other
mechanism to detect the configuraitons itself.
Exactly.
Also, the documentation seems have not updated to include
peer.config.
That's because it will be removed again.
--
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.
7:06 p.m.
On Thu, 2009-11-05 at 08:44 +0100, Patrick Ohly wrote:
On Thu, 2009-11-05 at 07:05 +0000, Chen, Congwu wrote:
> If the syncevo-dbus-server is supposed to work as a syncML server, the dus api
> Server.connect need peer.config to be set explictly to select the appropriate
> configuration.
This is a short-term workaround. The final solution will be that the
server analyzes the first SyncML message, extracts the device ID,
searches for the corresponding configuration, then runs a sync session
with that configuration.
Let's talk about details for this.
I had already tentatively added an internal "remoteDeviceID" property to
a peer configuration and left the deviceID as it was.
Further changes are needed:
- deviceID becomes a "per source set" configuration. It always stands
for the ID used by the local side, regardless whether it is acting
as server or client. As server the ID doesn't have much use, though,
except in special SAN messages to SyncEvolution (not implemented yet).
- remoteDeviceID must become a public property, because users and/or
frontends have to set it. Currently it is set automatically upon
first connect for the pre-chosen configuration. We want to get rid of
the need to choose the configuration in advance and replace it
with matching against existing remoteDeviceID properties, so these
values must get into the configurations somehow.
This "somehow" is unspecified at the moment. Some kind of
auto-provisioning would be useful: a device connects for the first time,
no config found, dialog comes up which asks how to sync, creates config.
--
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:16 p.m.
On Fri, 2009-11-06 at 08:06 +0000, Patrick Ohly wrote:
On Thu, 2009-11-05 at 08:44 +0100, Patrick Ohly wrote:
> On Thu, 2009-11-05 at 07:05 +0000, Chen, Congwu wrote:
> > If the syncevo-dbus-server is supposed to work as a syncML server, the dus api
> > Server.connect need peer.config to be set explictly to select the appropriate
> > configuration.
>
> This is a short-term workaround. The final solution will be that the
> server analyzes the first SyncML message, extracts the device ID,
> searches for the corresponding configuration, then runs a sync session
> with that configuration.
I have implemented this as part of the "server-config" branch. Congwu,
please review
commit 15b1de77b8de7abdb9bf672252e916e65ac20b76
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Nov 6 11:43:55 2009 +0100
SyncML server: find configuration for client automatically (MB#7710)
Let's talk about details for this.
I had already tentatively added an internal "remoteDeviceID" property to
a peer configuration and left the deviceID as it was.
Further changes are needed:
- deviceID becomes a "per source set" configuration. It always stands
for the ID used by the local side, regardless whether it is acting
as server or client. As server the ID doesn't have much use, though,
except in special SAN messages to SyncEvolution (not implemented yet).
- remoteDeviceID must become a public property, because users and/or
frontends have to set it. Currently it is set automatically upon
first connect for the pre-chosen configuration. We want to get rid of
the need to choose the configuration in advance and replace it
with matching against existing remoteDeviceID properties, so these
values must get into the configurations somehow.
This still needs to be done. Added to 7710.
This "somehow" is unspecified at the moment. Some kind of
auto-provisioning would be useful: a device connects for the first time,
no config found, dialog comes up which asks how to sync, creates config
Added a new issue: http://bugzilla.moblin.org/show_bug.cgi?id=7838
"creating client config"
--
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.
4:50 p.m.
Yes, it looks good ;-)
I have implemented this as part of the "server-config"
branch. Congwu,
please review
commit 15b1de77b8de7abdb9bf672252e916e65ac20b76
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Nov 6 11:43:55 2009 +0100
SyncML server: find configuration for client automatically (MB#7710)
Best regards,
Congwu
4696
days inactive
4700
days old
syncevolution@synevolution.org
4 comments
3 participants
participants (3)
-
Chen Congwu -
Chen, Congwu
-
Patrick Ohly