WM2003 synchronization: distribution integration

[Adam Williamson]

Hi, all!

So my WM2003 test device showed up yesterday. Following random internet
guides, I was able to get it sync'ing quite easily. The procedure is:

1. plug in the ipaq
2. run vdccm as normal user
3. run synce-serial-config ttyUSB0 as root
4. run synce-serial-start as root (if you run vdccm in foreground you
should it noticing the device now)
5. run 'synce-matchmaker create' to create a partnership
6. synchronize using your preferred opensync frontend and
libopensync-plugin-synce *from opensync, not the one from synce* (the
one from synce appears to work only with odccm)

this seems to work fine.

Now, to distro integration! The low-hanging fruit is obviously vdccm,
which can be set up to run as a service, same as odccm. Everything else
is more complicated. :)

Step three, ideally, isn't something the user should have to do, AFAICT.
Would it be crack to have it done automatically when the device is
plugged in, via udev rules? To phrase it differently, would there be any
reason someone would want to plug in an iPaq but *not* run
synce-serial-config to prepare it for synchronization?

Step four, same question as step three, I guess. Why is this designed as
a manually triggered action? Why would you ever *not* want to do this?
Should I have it done automatically? Should I stick it in the start
menu? Should synce-kpm or synce-trayicon be doing it?

Step five, clearly synce-kpm and synce-trayicon should be able to handle
this. I don't believe synce-kpm can, but I think synce-trayicon may;
I'll investigate that.

Step six I already have covered.

Thanks for any feedback :) Basically the questions about step three and
four are the most important; if someone can explain why they're set up
the way they are, it would be appreciated. Also, would the use of
hal-dccm change any of the above?

[John Carr]

On Sat, May 31, 2008 at 8:45 PM, Adam Williamson

Post by Adam Williamson
Hi, all!
So my WM2003 test device showed up yesterday. Following random internet
1. plug in the ipaq
2. run vdccm as normal user
3. run synce-serial-config ttyUSB0 as root
4. run synce-serial-start as root (if you run vdccm in foreground you
should it noticing the device now)
5. run 'synce-matchmaker create' to create a partnership
6. synchronize using your preferred opensync frontend and
libopensync-plugin-synce *from opensync, not the one from synce* (the
one from synce appears to work only with odccm)
this seems to work fine.
Now, to distro integration! The low-hanging fruit is obviously vdccm,
which can be set up to run as a service, same as odccm. Everything else
is more complicated. :)

odccm works just as well as vdccm in this scenario. I can't see any
real reasons to keep vdccm (or dccm) hanging around. Actually, i hope
to see odccm removed in favor of synce-hal before long.

Post by Adam Williamson
Step three, ideally, isn't something the user should have to do, AFAICT.
Would it be crack to have it done automatically when the device is
plugged in, via udev rules? To phrase it differently, would there be any
reason someone would want to plug in an iPaq but *not* run
synce-serial-config to prepare it for synchronization?

synce-hal should take care of this

Post by Adam Williamson
Step four, same question as step three, I guess. Why is this designed as
a manually triggered action? Why would you ever *not* want to do this?
Should I have it done automatically? Should I stick it in the start
menu? Should synce-kpm or synce-trayicon be doing it?

synce-hal should take care of this

Post by Adam Williamson
Step five, clearly synce-kpm and synce-trayicon should be able to handle
this. I don't believe synce-kpm can, but I think synce-trayicon may;
I'll investigate that.

My understanding is that KPM pokes sync-engine over dbus and that in
turn manipulates the devices registry to create partnerships. I'm not
sure if the synce-matchmaker program does the same or not.

Post by Adam Williamson
Step six I already have covered.

At this point, i think mark has had it working with the multisync
plugin. I presume the opensync synce plugin works at this point, too.
But we should probably bring that plugin into our fold as their synce
plugin doesnt work with opensync 0.3.

Post by Adam Williamson
Thanks for any feedback :) Basically the questions about step three and
four are the most important; if someone can explain why they're set up
the way they are, it would be appreciated. Also, would the use of
hal-dccm change any of the above?

They are set up that way because all the new shiny integration work is
newer than the bits of code you have been messing with. synce-hal
sweeps most of it away.

John

[Adam Williamson]

Post by John Carr
They are set up that way because all the new shiny integration work is
newer than the bits of code you have been messing with. synce-hal
sweeps most of it away.

Thanks for the info, John; I wasn't aware that synce-hal changed things
so much, I thought it was essentially just an alternative dccm but the
serial stuff would still have to be setup. I'll experiment with the HAL
stuff on Monday.

[Mark Ellis]

Post by John Carr
On Sat, May 31, 2008 at 8:45 PM, Adam Williamson

Post by Adam Williamson
Hi, all!

Hi !

John has this pretty much covered, I'll just add a few comments.

Post by John Carr

Post by Adam Williamson
So my WM2003 test device showed up yesterday. Following random internet
1. plug in the ipaq
2. run vdccm as normal user
3. run synce-serial-config ttyUSB0 as root
4. run synce-serial-start as root (if you run vdccm in foreground you
should it noticing the device now)
5. run 'synce-matchmaker create' to create a partnership
6. synchronize using your preferred opensync frontend and
libopensync-plugin-synce *from opensync, not the one from synce* (the
one from synce appears to work only with odccm)
this seems to work fine.
Now, to distro integration! The low-hanging fruit is obviously vdccm,
which can be set up to run as a service, same as odccm. Everything else
is more complicated. :)

odccm works just as well as vdccm in this scenario. I can't see any
real reasons to keep vdccm (or dccm) hanging around. Actually, i hope
to see odccm removed in favor of synce-hal before long.

The _only_ thing that needs vdccm is raki, in synce-kde. The _only_
reason to use raki (unless you just really like it) is to sync a WM2003
device in kde. I don't use kde, so I don't know if this is the only
option. When WM2003 support gets into sync-engine, it'll be a non-issue.

Post by John Carr

Post by Adam Williamson
Step three, ideally, isn't something the user should have to do, AFAICT.
Would it be crack to have it done automatically when the device is
plugged in, via udev rules? To phrase it differently, would there be any
reason someone would want to plug in an iPaq but *not* run
synce-serial-config to prepare it for synchronization?

synce-hal should take care of this

But if you really want to use synce-serial/odccm, there are notes in the
latest synce-serial README on how to automate this. In fact step 3 isn't
needed with the latest synce-serial.

Post by John Carr

Post by Adam Williamson
Step four, same question as step three, I guess. Why is this designed as
a manually triggered action? Why would you ever *not* want to do this?
Should I have it done automatically? Should I stick it in the start
menu? Should synce-kpm or synce-trayicon be doing it?

synce-hal should take care of this

Same as above, see the README.

Post by John Carr

Post by Adam Williamson
Step five, clearly synce-kpm and synce-trayicon should be able to handle
this. I don't believe synce-kpm can, but I think synce-trayicon may;
I'll investigate that.

My understanding is that KPM pokes sync-engine over dbus and that in
turn manipulates the devices registry to create partnerships. I'm not
sure if the synce-matchmaker program does the same or not.

synce-kpm doesn't do WM2003 at all, only WM5 and later. trayicon will do
this stuff for all versions. At least no one has yet reported a
breakage :)

Post by John Carr

Post by Adam Williamson
Step six I already have covered.

At this point, i think mark has had it working with the multisync
plugin. I presume the opensync synce plugin works at this point, too.
But we should probably bring that plugin into our fold as their synce
plugin doesnt work with opensync 0.3.

Interesting, are you saying you've tried the opensync distributed synce
plugin, and it works with WM2003 ? I've never tried it, always used the
legacy multisync one.

Post by John Carr

Post by Adam Williamson
Thanks for any feedback :) Basically the questions about step three and
four are the most important; if someone can explain why they're set up
the way they are, it would be appreciated. Also, would the use of
hal-dccm change any of the above?

They are set up that way because all the new shiny integration work is
newer than the bits of code you have been messing with. synce-hal
sweeps most of it away.

Indeed !

Mark

[Adam Williamson]

Post by Mark Ellis
Interesting, are you saying you've tried the opensync distributed synce
plugin, and it works with WM2003 ? I've never tried it, always used the
legacy multisync one.

Yep, I used it, it worked. not much else to say, really. :)