10:08 a.m.
Hello!
The source for SyncEvolution 0.9.1 is on the "master" branch of the
libsynthesis and syncevolution moblin.org repo.
For the development version leading towards 1.0, please use:
* "dbus-api" in the syncevolution repo
* "multilib" in the libsynthesis repo
The Server Alerted Notification support was merged in the development
branches, so the older "san" branch is obsolete. Regarding SAN support
in the syncevo-dbus-server, the main difference is that the content of a
SAN message now really controls which sources are synchronized.
Previously, sending a SAN message triggered a sync with the settings
stored in the configuration. This change is several weeks old with no
further changes since then, except for merging it into the regular code.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax: +49-2232-2090-29
Germany
10:36 a.m.
Hi Patrick,
Thank you for update. Congwu has helped me to update to the right git branch of
syncevolution and libsynthesis yesterday. My status is: the code for OBEX server/SyncML
client binding is done; now I'm doing unit testing. Will send out the patch to obexd
mailing list for review soon (in about 1 -2 days).
Thanks,
Forrest
-----Original Message-----
From: Ohly, Patrick
Sent: 2009年10月15日 16:09
To: SyncEvolution
Cc: Zhao, Forrest
Subject: git status update
Hello!
The source for SyncEvolution 0.9.1 is on the "master" branch of the
libsynthesis and syncevolution moblin.org repo.
For the development version leading towards 1.0, please use:
* "dbus-api" in the syncevolution repo
* "multilib" in the libsynthesis repo
The Server Alerted Notification support was merged in the development
branches, so the older "san" branch is obsolete. Regarding SAN support
in the syncevo-dbus-server, the main difference is that the content of a
SAN message now really controls which sources are synchronized.
Previously, sending a SAN message triggered a sync with the settings
stored in the configuration. This change is several weeks old with no
further changes since then, except for merging it into the regular code.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax: +49-2232-2090-29
Germany
10:47 a.m.
New subject: [SyncEvolution] git status update + obexd update
On Thu, 2009-10-15 at 09:36 +0100, Zhao, Forrest wrote:
Thank you for update. Congwu has helped me to update to the right
git
branch of syncevolution and libsynthesis yesterday. My status is: the
code for OBEX server/SyncML client binding is done; now I'm doing unit
testing. Will send out the patch to obexd mailing list for review soon
(in about 1 -2 days).
Excellent. Can you post an example "dbus-monitor" dump of the initial
org.syncevolution.Server.Connect() call? I'd like to have a look at what
information is available to SyncEvolution when it is contacted by obexd.
Congwu mentioned that some workarounds were necessary in SyncEvolution
because the libsyncml test tool didn't set the message type correctly.
What exactly was the workaround - patch?
With libsyncml, we can fix the sender. That might not be the case in
other situations. So should we make this workaround an official part of
the D-Bus API and obexd implementation, for example by declaring the
message type as optional so that SyncEvolution knows that it might have
to guess the type?
--
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.
11:06 a.m.
New subject: [SyncEvolution] git status update + obexd update
Patrick wrote:
Congwu mentioned that some workarounds were necessary in
SyncEvolution
because the libsyncml test tool didn't set the message type correctly.
What exactly was the workaround - patch?
Two workarounds:
1) DEV_TYPE, why are we using desktop? Libsyncml is fairly stick on this and does not
accept device types not mentioned in the mandatory list. Shall we change it to something
like workstation?
2) The SAN message type as you already know. I think let SyncEvolution to guess the type
is a real solution. I may come up with this if no disagree.
Also though SAN message parsing is enabled, obexd test with libsyncml still used the fixed
"default" configuration. I think this is more like an interoperability issue and
is safe to ignore from transport implementation's eye.
With libsyncml, we can fix the sender. That might not be the case in
other situations. So should we make this workaround an official part of
the D-Bus API and obexd implementation, for example by declaring the
message type as optional so that SyncEvolution knows that it might have
to guess the type?
For the development version leading towards 1.0, please use:
* "dbus-api" in the syncevolution repo
* "unilib" in the libsynthesis repo
I have also rebased my obex
branch against dbus-api and am improving it to remove any blocking calls.
Hoping we will start real test with Forrest's Obexd and SyncEvolution server.
--
Best Regards,
Congwu
11:38 a.m.
New subject: [SyncEvolution] git status update + obexd update
On Thu, 2009-10-15 at 10:06 +0100, Chen, Congwu wrote:
Patrick wrote:
>Congwu mentioned that some workarounds were necessary in SyncEvolution
>because the libsyncml test tool didn't set the message type correctly.
>What exactly was the workaround - patch?
Two workarounds:
1) DEV_TYPE, why are we using desktop?
No particular reason. It seemed more appropriate than "workstation",
that's all.
Libsyncml is fairly stick on this and does not accept device types
not mentioned in the mandatory list. Shall we change it to something
like workstation?
Yes, we should do that.
2) The SAN message type as you already know. I think let
SyncEvolution
to guess the type is a real solution. I may come up with this if no
disagree.
Yes, please do.
Also though SAN message parsing is enabled, obexd test with
libsyncml
still used the fixed "default" configuration. I think this is more
like an interoperability issue and is safe to ignore from transport
implementation's eye.
Agreed, although we should look into to determine why this happens. The
SAN message parsing code has extensive logging, so checking stdout of
the syncevo-dbus-server might help, plus of course single-stepping
through the code in a debugger.
--
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.
3:21 a.m.
New subject: [SyncEvolution] git status update + obexd update
Ohly, Patrick wrote:
On Thu, 2009-10-15 at 09:36 +0100, Zhao, Forrest wrote:
> Thank you for update. Congwu has helped me to update to the right git
> branch of syncevolution and libsynthesis yesterday. My status is: the
> code for OBEX server/SyncML client binding is done; now I'm doing
> unit testing. Will send out the patch to obexd mailing list for
> review soon (in about 1 -2 days).
Excellent. Can you post an example "dbus-monitor" dump of the initial
org.syncevolution.Server.Connect() call? I'd like to have a look at
what information is available to SyncEvolution when it is contacted
by obexd.
I attached the "dbus-monitor" dump of org.syncevolution.Server.Connect()
call. FYI.
Thanks,
Forrest
11:29 a.m.
New subject: [SyncEvolution] git status update + obexd update
On Fri, 2009-10-16 at 02:21 +0100, Zhao, Forrest wrote:
Ohly, Patrick wrote:
> On Thu, 2009-10-15 at 09:36 +0100, Zhao, Forrest wrote:
>> Thank you for update. Congwu has helped me to update to the right git
>> branch of syncevolution and libsynthesis yesterday. My status is: the
>> code for OBEX server/SyncML client binding is done; now I'm doing
>> unit testing. Will send out the patch to obexd mailing list for
>> review soon (in about 1 -2 days).
>
> Excellent. Can you post an example "dbus-monitor" dump of the initial
> org.syncevolution.Server.Connect() call? I'd like to have a look at
> what information is available to SyncEvolution when it is contacted
> by obexd.
>
I attached the "dbus-monitor" dump of org.syncevolution.Server.Connect() call.
FYI.
method call sender=:1.344 -> dest=org.syncevolution
path=/org/syncevolution/Server; interface=org.syncevolution.Server;
member=Connect
array [
dict entry(
string "description"
string "obexd stub"
)
dict entry(
string "transport"
string "org.openobex"
)
]
Can you add more information? The following keys are currently defined:
"description" - a description of the peer in a format and
language that is understood by the user.
You are sending "obexd stub", but we need something about the remote
OBEX peer, like the device description (whatever is available - I don't
know).
"id" - a unique ID for this particular peer, in a format
that is specific to the transport. The ID only has to be
unique among peers using that transport at the current
point in time.
For OBEX over Bluetooth we need the MAC address. From what Lukas told us
about his experience with SAN as used by e.g. Nokia's PC Suite, the
server doesn't put something unique into the SAN message itself. The
client is supposed to identify the server via the connection's meta
information.
"transport_description" - could be used to describe the
version of the transport entity.
Can you add an obexd version number?
--
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.
11:09 a.m.
New subject: [SyncEvolution] git status update + obexd update
Can you add more information? The following keys are currently
defined:
"description" - a description of the peer in a format and
language that is understood by the user.
You are sending "obexd stub", but we need something about the remote
OBEX peer, like the device description (whatever is available - I
don't know).
In updated version I keep "description" as "obexd stub". I could set
"description" the same as "id" (i.e. BT MAC address + channel number)
to identify the remote OBEX peer if you like.
"id" - a unique ID for this particular peer, in a format
that is specific to the transport. The ID only has to be
unique among peers using that transport at the current
point in time.
"id" is set to BT MAC address + channel number, which could identify the
remote OBEX peer uniquely.
For OBEX over Bluetooth we need the MAC address. From what Lukas
told
us about his experience with SAN as used by e.g. Nokia's PC Suite, the
server doesn't put something unique into the SAN message itself. The
client is supposed to identify the server via the connection's meta
information.
"transport_description" - could be used to describe the
version of the transport entity.
Can you add an obexd version number?
obexd version number is added. The below is
dump of dbus-monitor:
method call sender=:1.357 -> dest=org.syncevolution path=/org/syncevolution/Server;
interface=org.syncevolution.Server; member=Connect
array [
dict entry(
string "description"
string "obexd stub"
)
dict entry(
string "id"
string "00:0A:94:03:EB:E5, channel 16"
)
dict entry(
string "transport"
string "org.openobex, version 0.18"
)
]
boolean false
string ""
11:49 a.m.
New subject: [SyncEvolution] git status update + obexd update
On Mon, 2009-10-19 at 10:09 +0100, Zhao, Forrest wrote:
>
> Can you add more information? The following keys are currently
> defined:
>
> "description" - a description of the peer in a format and
> language that is understood by the user.
>
> You are sending "obexd stub", but we need something about the remote
> OBEX peer, like the device description (whatever is available - I
> don't know).
In updated version I keep "description" as "obexd stub". I could set
"description" the same as "id" (i.e. BT MAC address + channel
number)
to identify the remote OBEX peer if you like.
If you can't get device information about the peer, then please leave
out "description" entirely. If we use the "description" as specified
(string which is visible to users), then both "obexd stub" and MAC
address would be confusing.
This doesn't solve the problem of GUI integration, but we can defer that
until later.
> "id" - a unique ID for this particular
peer, in a format
> that is specific to the transport. The ID only has to be
> unique among peers using that transport at the current
> point in time.
>
"id" is set to BT MAC address + channel number, which could identify the remote
OBEX peer uniquely.
I was about to ask about the format when I saw you example below. Can we
make it slightly more machine readable, perhaps like this?
00:0A:94:03:EB:E5+16
> For OBEX over Bluetooth we need the MAC address. From what Lukas
told
> us about his experience with SAN as used by e.g. Nokia's PC Suite, the
> server doesn't put something unique into the SAN message itself. The
> client is supposed to identify the server via the connection's meta
> information.
>
> "transport_description" - could be used to describe the
> version of the transport entity.
>
> Can you add an obexd version number?
obexd version number is added.
Please put it into "transport_description", not "transport". While we
are at it, perhaps append "obexd" to ensure that we don't get conflicts
later on; "org.openobex" could host multiple programs talking to
SyncEvolution.
=> "transport" = "org.openobex.obexd"
"transport_description" = "version 0.18"
--
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:57 a.m.
New subject: [SyncEvolution] git status update + obexd update
>>
> "id" is set to BT MAC address + channel number, which could identify
> the remote OBEX peer uniquely.
I was about to ask about the format when I saw you example below. Can
we make it slightly more machine readable, perhaps like this?
00:0A:94:03:EB:E5+16
Please put it into "transport_description", not "transport". While
we
are at it, perhaps append "obexd" to ensure that we don't get
conflicts later on; "org.openobex" could host multiple programs
talking to SyncEvolution.
=> "transport" = "org.openobex.obexd"
"transport_description" = "version 0.18"
Code is updated according to your request. The below is the dbus-monitor dump
method call sender=:1.364 -> dest=org.syncevolution path=/org/syncevolution/Server;
interface=org.syncevolution.Server; member=Connect
array [
dict entry(
string "id"
string "00:0A:94:03:EB:E5+16"
)
dict entry(
string "transport"
string "org.openobex.obexd"
)
dict entry(
string "transport_description"
string "version 0.18"
)
]
boolean false
string ""
BTW. I submit the patch to #obexd IRC channel last Friday, but there's no response
from Marcel until now. So I decide the re-send the patch to BlueZ mailing list and CC
you.
Thanks,
Forrest
10:49 a.m.
On Thu, 2009-10-15 at 10:08 +0200, Patrick Ohly wrote:
For the development version leading towards 1.0, please use:
* "dbus-api" in the syncevolution repo
* "multilib" in the libsynthesis repo
^^^^^^^^
Typo, I meant "unilib" :-/
--
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.
4596
days inactive
4601
days old
syncevolution@synevolution.org
10 comments
3 participants
participants (3)
-
Chen, Congwu -
Patrick Ohly -
Zhao, Forrest