synce-hal

[Mark Ellis]

Hi All

As some will have noticed, Jonny just released synce-hal 0.1 for me.
This seemed an appropriate time to explain what I've been going on about
lately ! Apologies for the cross posting, just in case some devel'ers
are on users. Some of this may be more than the users want to know as
well.

synce-hal is basically a replacement for odccm, but tries to handle a
lot more of the connection process. It provides an addon for hal, which
is called by hal whenever a WM device is connected. We're going for full
plug and play here.

For pre WM5 devices, a ppp connection is first established. For WM5 and
later, a ppp connection is used if the device is in legacy mode, or if
using rndis (preferred) the interface is configured with dhcp, falling
back to a static configuration if dhcp fails. hal-dccm is then called
for any of these scenarios, as a per-device process, which exits when
hal detects the device has been disconnected.

All this is transparent to the user. For ppp users, the synce-serial
package is no longer required. Rndis still needs the usb-rndis-lite
kernel module, there's not much we can do about this until the fixes get
into the kernel. Make sure odccm isn't running.

Device properties eg. name and os version, are advertised in hal, and so
are available to anything that is interested and can search hal, with no
modification. Have a look at your device in hal device-manager for
instance.

Client connections (rapi) and password unlocking are handled as a hal
dbus interface. All the core libraries and synce-trayicon have the
necessary changes in place in the latest releases. sync-engine in
subversion will also work. The only package that will need modification
is synce-kpm, there is a possibly working patch included in the patches
subdir of synce-hal.

For the more adventurous, there are some instructions and scripts to
connect over bluetooth, in the bluetooth subdir.

I hope you all have fun with this, it's turned out to be quite a robust
and extensible framework. An unexpected side benefit has been some
freeBSD'ers successfully connecting after odccm didn't work for them.
We'll also eventually be able to tie in to more generalised sync
frameworks under development.

Any comments / problems / rants more than welcome.

Mark

[Jonny Lamb]

[Replying to Mark as well as CC'ing the list as others might find it
interesting.]

Post by Mark Ellis
synce-hal is basically a replacement for odccm, but tries to handle a
lot more of the connection process. It provides an addon for hal, which
is called by hal whenever a WM device is connected. We're going for full
plug and play here.

I've been preparing Debian packages for hal-dccm recently, and I have
some queries:

synce-hal produces four executables: hal-dccm, synce-serial-chat,
hal-synce-rndis and hal-synce-serial. All four of these are installed
into $prefix/libexec, which is bad for Debian. I see in your synce-hal
package you've installed the hal-synce-* files into /usr/lib/hal/, but
I'm unsure as to the proper location of the others.

So, why did you install the four executables into $libexecdir? Do any of
the executables require root? My understanding is that the hal-synce-*
scripts will be called by hal upon a device connection, so they'll be
run as root, and therefore so will hal-dccm and synce-serial-start, but
I could be wrong.. Therefore I am emailing just to be clear, so I don't
screw up the package.

Many thanks,

[Mark Ellis]

Post by Jonny Lamb
[Replying to Mark as well as CC'ing the list as others might find it
interesting.]

Post by Mark Ellis
synce-hal is basically a replacement for odccm, but tries to handle a
lot more of the connection process. It provides an addon for hal, which
is called by hal whenever a WM device is connected. We're going for full
plug and play here.

I've been preparing Debian packages for hal-dccm recently, and I have

The problem here is that I haven't found a reliable way of determining
where hal addons/callouts go. Obviously _I_ know where they go :) but
configure doesn't.

Post by Jonny Lamb
synce-hal produces four executables: hal-dccm, synce-serial-chat,
hal-synce-rndis and hal-synce-serial. All four of these are installed
into $prefix/libexec, which is bad for Debian. I see in your synce-hal
package you've installed the hal-synce-* files into /usr/lib/hal/, but
I'm unsure as to the proper location of the others.
So, why did you install the four executables into $libexecdir? Do any of
the executables require root? My understanding is that the hal-synce-*
scripts will be called by hal upon a device connection, so they'll be
run as root, and therefore so will hal-dccm and synce-serial-start, but
I could be wrong.. Therefore I am emailing just to be clear, so I don't
screw up the package.

libexec is the closest approximation

hal-dccm and synce-serial-chat are true libexec, so on debian go
in /usr/lib/<packagename>, ie /usr/lib/synce-hal. They are only called
internally so the exact location is not vital.

hal-synce-* are the problem, they go in the hal addon location, which is
poorly defined. On debian it's the hal libexecdir, ie /usr/lib/hal.

Your understanding of how the process works is correct, everything
initially comes from hal, so runs as root anyway.

Mark