synce hal...

[Mark Ellis]

... seemed the most appropriate name, since it's not just dccm.

I've committed my attempt at this for your delight and delectation, if
anyone wants to give it a go it would be much appreciated.

The idea is it should just work, no config required. I've had my WM2003
device connected and able to respond to rapi calls. First remove
anything else that will interfere, like udev rules etc. Feedback on WM5
would be great.

You will need a patched libsynce and librapi, use the provided patches
in the 'patches' dir. I didn't want to commit these until after Jonny
releases 0.11.

Passworded devices will not currently work.

For you inquisitive types, you'll probably notice a lot of junk in the
logs and code, this is still work in progress.

John (Carr), since this was all your fault :) , assuming it works with
whatever you're using, can you take a glance over the results in
hal-device-manager or similar and see if you think I've got the right
idea.

Mark

[Vasco Steinmetz]

Hi all,

another patch to update the (now again broken :) Gentoo SVN ebuilds.

Because there are already stable 0.10 packages available on the site and accessible via layman, and additionaly there's ast least
one existing upstream package (synce-kde-0.6.1 to 0.9.1) still depending on synce-rra, I decided to keep the synce-rra-0.10 ebuild
as long as 0.10 is available to counter breaking existing non-SVN installations.

So I simply copied the existing synce-rra-9999 over to synce-librra-9999 and fixed the synce-sync-engine-9999 ebuild to depend on
it. Notze-bien: synce-sync-engine-0.10 still depends on synce-rra-0.10!

You have to remove the installed version of synce-rra first by "emerge -C synce-rra" and then emerge synce-lib.

Digests fixed.

Comments welcome.


Cheers,
Vasco

[Richard Alimi]

I'll try to look at this and apply it tonight. Thanks!

--
Richard Alimi
Department of Computer Science
Yale University

Post by Vasco Steinmetz
Hi all,
another patch to update the (now again broken :) Gentoo SVN ebuilds.
Because there are already stable 0.10 packages available on the site and
accessible via layman, and additionaly there's ast least one existing
upstream package (synce-kde-0.6.1 to 0.9.1) still depending on synce-rra, I
decided to keep the synce-rra-0.10 ebuild as long as 0.10 is available to
counter breaking existing non-SVN installations.
So I simply copied the existing synce-rra-9999 over to synce-librra-9999
synce-sync-engine-0.10 still depends on synce-rra-0.10!
You have to remove the installed version of synce-rra first by "emerge -C
synce-rra" and then emerge synce-lib.
Digests fixed.
Comments welcome.
Cheers,
Vasco

[Vasco Steinmetz]

Post by Vasco Steinmetz
You have to remove the installed version of synce-rra first by "emerge
-C synce-rra" and then emerge synce-lib.

Should read: "... and then emerge synce-librra synce-sync-engine."

Sorry for the typo.


Cheers,
Vasco

[Richard Alimi]

Hi Vasco,

Post by Vasco Steinmetz
Because there are already stable 0.10 packages available on the site and
accessible via layman, and additionaly there's ast least one existing
upstream package (synce-kde-0.6.1 to 0.9.1) still depending on synce-rra, I
decided to keep the synce-rra-0.10 ebuild as long as 0.10 is available to
counter breaking existing non-SVN installations.
So I simply copied the existing synce-rra-9999 over to synce-librra-9999
synce-sync-engine-0.10 still depends on synce-rra-0.10!
You have to remove the installed version of synce-rra first by "emerge -C
synce-rra" and then emerge synce-lib.

There were a few things missing from your patch, but I tried to fill them in.
I haven't tried building after my commit, but give it a try and let me know
how it goes.

Thanks for the contribution!

[Jonny Lamb]

Post by Mark Ellis
I've committed my attempt at this for your delight and delectation, if
anyone wants to give it a go it would be much appreciated.

Wow, interested! I'm not actually very sure what this is, but I'm still
interested! A short description would be nice..?! :-) I shall definitely
give it a go once my todo list is slightly shorter!

Post by Mark Ellis
The idea is it should just work, no config required. I've had my WM2003
device connected and able to respond to rapi calls. First remove
anything else that will interfere, like udev rules etc. Feedback on WM5
would be great.

By "no config required", what config do you speak of? After all, getting
to the stage of being able to "pls" to one's phone is rather config-less
is it not?

Post by Mark Ellis
You will need a patched libsynce and librapi, use the provided patches
in the 'patches' dir. I didn't want to commit these until after Jonny
releases 0.11.

Thank you for understanding this..!

Post by Mark Ellis
John (Carr), since this was all your fault :) , assuming it works with
whatever you're using, can you take a glance over the results in
hal-device-manager or similar and see if you think I've got the right
idea.

Thanks!

[Mark Ellis]

Post by Jonny Lamb

Post by Mark Ellis
I've committed my attempt at this for your delight and delectation, if
anyone wants to give it a go it would be much appreciated.

Wow, interested! I'm not actually very sure what this is, but I'm still
interested! A short description would be nice..?! :-) I shall definitely
give it a go once my todo list is slightly shorter!

It's a hal callout framework with compatible dccm. That sounds good and
means nothing doesn't it :) This is what John Carr and myself have been
discussing.

Ok, more usefully, it installs a hal fdi (device information file) for
WM devices, currently set to recognise devices by rndis_host or ipaq
driver information, or "pocketpc" string for rndis-ng (like odccm).

When hal discovers one of these it calls a script to bring up the
interface, be it rndis or ppp, which then calls the dccm.

This does pretty much what every dccm we have had does, but via hal. The
device information is published as hal properties rather than over dbus
(well hal is over dbus anyway, but you get my meaning), so if you look
at the device in hal-device-manager you'll see properties, prefixed
pda.pocketpc, such as name, os version and model. The methods to obtain
a rapi connection and provide a password are the same, but through a hal
interface rather than our own, these are passed through to dccm by hal.

Each device also gets its own dccm, which terminates when hal detects
the device is disconnected, so no redundant processes or boot scripts.
Note, multi device won't work yet, gnet is being wierd with binding to a
specific interface, but I will be able to fix this eventually.

Post by Jonny Lamb

Post by Mark Ellis
The idea is it should just work, no config required. I've had my WM2003
device connected and able to respond to rapi calls. First remove
anything else that will interfere, like udev rules etc. Feedback on WM5
would be great.

By "no config required", what config do you speak of? After all, getting
to the stage of being able to "pls" to one's phone is rather config-less
is it not?

Mostly referring to pre WM5, the serial stuff is all figured out on the
fly. Also as mentioned above, dccm will fire up when required, it
doesn't need a boot script or user intervention.

Post by Jonny Lamb

Post by Mark Ellis
You will need a patched libsynce and librapi, use the provided patches
in the 'patches' dir. I didn't want to commit these until after Jonny
releases 0.11.

Thank you for understanding this..!

No worries :) It's all backwards compatible and unlikely to break, but
wasn't worth the hassle yet.

With the small patches to libsynce and librapi, anything using pure rapi
calls won't notice any difference. Anything that needs more direct
access will only need minor fixes to call hal instead of odccm. For C
applications libhal does the job splendidly. I haven't found an
equivalent for python, but it's just a case of tweaking the dbus
interface we use.

If Guido and Dr John are reading, I found a nice example at

http://davyd.livejournal.com/206645.html

All logging goes to syslog local5 if you want to keep an eye on things.
At the moment it'll spurt out various amounts of experimental stuff as
well.

Mark

[Guido Diepen]

Post by Mark Ellis

Post by Jonny Lamb

Post by Mark Ellis
You will need a patched libsynce and librapi, use the provided patches
in the 'patches' dir. I didn't want to commit these until after Jonny
releases 0.11.

Thank you for understanding this..!

No worries :) It's all backwards compatible and unlikely to break, but
wasn't worth the hassle yet.
With the small patches to libsynce and librapi, anything using pure rapi
calls won't notice any difference. Anything that needs more direct
access will only need minor fixes to call hal instead of odccm. For C
applications libhal does the job splendidly. I haven't found an
equivalent for python, but it's just a case of tweaking the dbus
interface we use.

Within python we make use of pyrapi, which are nothing but wrappers around the
C rapi functions. So we should not have any problems at all with this
transition within python either.

Post by Mark Ellis
If Guido and Dr John are reading, I found a nice example at
http://davyd.livejournal.com/206645.html

At least for synce-kpm it is not needed, since I only make use of rapi calls,
which are wrapped around the original C rapi calls.

Guido Diepen

[Mark Ellis]

Post by Guido Diepen

Post by Mark Ellis

Post by Jonny Lamb

Post by Mark Ellis
You will need a patched libsynce and librapi, use the provided patches
in the 'patches' dir. I didn't want to commit these until after Jonny
releases 0.11.

Thank you for understanding this..!

No worries :) It's all backwards compatible and unlikely to break, but
wasn't worth the hassle yet.
With the small patches to libsynce and librapi, anything using pure rapi
calls won't notice any difference. Anything that needs more direct
access will only need minor fixes to call hal instead of odccm. For C
applications libhal does the job splendidly. I haven't found an
equivalent for python, but it's just a case of tweaking the dbus
interface we use.

Within python we make use of pyrapi, which are nothing but wrappers around the
C rapi functions. So we should not have any problems at all with this
transition within python either.

Post by Mark Ellis
If Guido and Dr John are reading, I found a nice example at
http://davyd.livejournal.com/206645.html

At least for synce-kpm it is not needed, since I only make use of rapi calls,
which are wrapped around the original C rapi calls.

I haven't had a thorough look through synce-kpm, but you'd need to make
these changes in util/CeDevice.py and util/commutil.py. When it's more
complete I'll try and put a patch together as an example, I'm still
learning the "raw" dbus calls to hal.

Mark

[Jonny Lamb]

Post by Mark Ellis
Ok, more usefully, it installs a hal fdi (device information file) for
WM devices, currently set to recognise devices by rndis_host or ipaq
driver information, or "pocketpc" string for rndis-ng (like odccm).
When hal discovers one of these it calls a script to bring up the
interface, be it rndis or ppp, which then calls the dccm.
This does pretty much what every dccm we have had does, but via hal. The
device information is published as hal properties rather than over dbus
(well hal is over dbus anyway, but you get my meaning), so if you look
at the device in hal-device-manager you'll see properties, prefixed
pda.pocketpc, such as name, os version and model. The methods to obtain
a rapi connection and provide a password are the same, but through a hal
interface rather than our own, these are passed through to dccm by hal.

This is fit! Go you! I will definitely be using this soon.

Post by Mark Ellis
Mostly referring to pre WM5, the serial stuff is all figured out on the
fly. Also as mentioned above, dccm will fire up when required, it
doesn't need a boot script or user intervention.

Ah I see, you legacy boys!