Discussion:
[Synce-devel] 0.11 and other talking points
Jonny Lamb
2007-12-05 15:32:26 UTC
Permalink
Hi everyone.

A fairly long email with some various thoughts on several things. This
is meant to spark up discussion, so please do reply!

0.11
====

I think this needs to be released pretty soon. However, there are some
things that need to be sorted first:

* Documentation -- yes this is the obvious one. Nothing really to say
about this.
* Various fixes -- known bugs in the software that don't require a
whole new rewrite should really be fixed before the release. Please
can you all reply with problems that spring to mind when I speak
about this, so I can keep track of the progress.

Rather a general "what needs to be done" list. Please do reply with
specifics! I suppose I'm suggesting we put in a freeze now and
concentrate on bugs, for the release.

0.10.0 to 0.11 (There's no point in an extra ".0" in "0.11" as there's
not going to be a "0.11.1" -- "0.10.0" was perhaps a little optimistic!)
isn't going to be the biggest update ever, but there are several nice
new features or fixes. Things that come to my mind now:

* Samsung SC* phones fixed with usb-rndis-lite.
* odccm now supports legacy devices.
* WM6 support.
* Various other fixes in SyncEngine.

Again, please fill the gaps here.

I think a new release will be very good for the project. It will provide
milestones that will be acceptable and doable for developers. It will
show SynCE as still being active and the new docs will make the project
more usable. The docs are currently what is stopping me pursuing
actually getting packages into Debian (and then perhaps Ubuntu), so that
would be started again.

Further goals
=============

After 0.11 there will be some other features and fixes that will be
worth investing time in. Two I can think of now are:

* Simplifying the installation process, significantly.
* Removing the libwbxml dependency.

If you have any other ideas, please state them here. If the idea has not
previously been aired, please give some information about it.

Other talking points
====================

vdccm: It seems to me that the only advantage of vdccm is its multiple
device support. Therefore, I am suggesting dropping vdccm as a proper
SynCE module. I'm not saying it should be deleted from SVN, but just
left out of releases. Thoughts?

ML moderator: I am currently looking for someone who will help out by
moderating the mailing lists. This basically takes two minutes every few
days or so and involves just filtering out spam from real mail. This
effort keeps the SynCE mailing lists spam-free. Email me if you are
interested in helping out, or would like to know more.

UK meetup: There are a few of us in the UK (myself, John Carr, J. A.
Gow, Mark Ellis, more?) -- John Carr and myself have spoken about
meeting up but I've been tremendously busy this term starting uni and
all that. Would anybody be interested in this?

I hope this is easy to read and is not too boring! :-)

Kind regards,
--
Jonny Lamb, UK ***@jonnylamb.com
http://jonnylamb.com GPG: 0x2E039402
John Carr
2007-12-05 16:29:10 UTC
Permalink
Lo all
Post by Jonny Lamb
Hi everyone.
A fairly long email with some various thoughts on several things. This
is meant to spark up discussion, so please do reply!
0.11
====
I think this needs to be released pretty soon. However, there are some
* Documentation -- yes this is the obvious one. Nothing really to say
about this.
I tried to start discussion about this earlier - mainly the best way to
structure the new wiki stuff and specifically how to deal with distrubtuion
specific bits without the duplication getting crazy.

* Various fixes -- known bugs in the software that don't require a
Post by Jonny Lamb
whole new rewrite should really be fixed before the release. Please
can you all reply with problems that spring to mind when I speak
about this, so I can keep track of the progress.
Rather a general "what needs to be done" list. Please do reply with
specifics! I suppose I'm suggesting we put in a freeze now and
concentrate on bugs, for the release.
Stuff I had wanted to see before 0.11:

* Data loss bug on WM6 phones when partnership is deleted - jagow is close
on that
* Mess with wbxml. I have some basic pure python wbxml that we could think
about using, but i'm almost ashamed to admit it right now - not really had
time for it and code is a messy port of some PHP
* HAL integration - a HAL callout that:
* dhcp-ifies a device
* starts odccm with the ips that dhcp sorted out (if not running)
* starts sync-engine (if not running)

If this doesn't make it for 0.11, any objections to a 0.12 closely following
when these bits are ready?

0.10.0 to 0.11 (There's no point in an extra ".0" in "0.11" as there's
Post by Jonny Lamb
not going to be a "0.11.1" -- "0.10.0" was perhaps a little optimistic!)
isn't going to be the biggest update ever, but there are several nice
* Samsung SC* phones fixed with usb-rndis-lite.
* odccm now supports legacy devices.
* WM6 support.
* Various other fixes in SyncEngine.
Again, please fill the gaps here.
I think a new release will be very good for the project. It will provide
milestones that will be acceptable and doable for developers. It will
show SynCE as still being active and the new docs will make the project
more usable. The docs are currently what is stopping me pursuing
actually getting packages into Debian (and then perhaps Ubuntu), so that
would be started again.
Have been in talks with Ubuntu (wrt Conduit and sync that "just works" - you
plug it in and it says "where sync to.. k thx bye") and its likely that
we'll see some support into pulling the latest and greatest into the next
release (probably more in terms of acceptance rather than actual man
hours)...

Further goals
Post by Jonny Lamb
=============
After 0.11 there will be some other features and fixes that will be
* Simplifying the installation process, significantly.
Helping main distros get everything packaged and the hal callout i mentioned
should do this.

I'd like to see odccm be per device if its possible. And use HAL to close
each odccm when its own device is removed.. Any device properties should be
stashed in HAL rather than apps having to talk to odccm. It seems a large
chunk of odccm is boilerplate :-(

In terms of supporting device passwords, blackberry also works in a similar
way and i'm pushing for some freedesktop-ish hook for storing passwords in
the keyring so that they can be automatically unlocked - where we share as
much as possible with barry (which is effectively the synce of blackberry)

* Removing the libwbxml dependency.
Post by Jonny Lamb
If you have any other ideas, please state them here. If the idea has not
previously been aired, please give some information about it.
There is no "modern" way to sync 2003 devices. You seem to have to use
ancient programs like a pre-opensync version of multisync. About 1 in 5
#synce requests is WM2003 related... That was a guess. Enough for it to
bother me that we don't offer support any more :P
Post by Jonny Lamb
Other talking points
====================
vdccm: It seems to me that the only advantage of vdccm is its multiple
device support. Therefore, I am suggesting dropping vdccm as a proper
SynCE module. I'm not saying it should be deleted from SVN, but just
left out of releases. Thoughts?
I presume vdcccm won't support WM6? It also doesn't work with sync-engine.
Unfortunately dropping it hurts KDE users, who often ask about RAKI. I have
no idea what exactly that is, but seems not to work with odccm. Yet. I am
strongly in favor of having just one *dccm. Either RAKI support in odccm or
another standalone proggy, or vdccm needs to be extended for WM6 and needs
to be made to work with sync-engine?

ML moderator: I am currently looking for someone who will help out by
Post by Jonny Lamb
moderating the mailing lists. This basically takes two minutes every few
days or so and involves just filtering out spam from real mail. This
effort keeps the SynCE mailing lists spam-free. Email me if you are
interested in helping out, or would like to know more.
UK meetup: There are a few of us in the UK (myself, John Carr, J. A.
Gow, Mark Ellis, more?) -- John Carr and myself have spoken about
meeting up but I've been tremendously busy this term starting uni and
all that. Would anybody be interested in this?
Meeting ++;

Though not sure where :-)

I hope this is easy to read and is not too boring! :-)
Post by Jonny Lamb
Kind regards,
--
http://jonnylamb.com GPG: 0x2E039402
John
Jonny Lamb
2007-12-05 17:08:21 UTC
Permalink
Hi.
Post by John Carr
* Data loss bug on WM6 phones when partnership is deleted - jagow is
close on that
Agreed.
Post by John Carr
* Mess with wbxml. I have some basic pure python wbxml that we could
think about using, but i'm almost ashamed to admit it right now - not
really had time for it and code is a messy port of some PHP
Is that based on the PHP-based Exchange/Activesync server/application
that I was linked to from #synce? I definitely think this is important,
but perhaps not enough to work on before 0.11..
Post by John Carr
* dhcp-ifies a device
* starts odccm with the ips that dhcp sorted out (if not running)
* starts sync-engine (if not running)
If this doesn't make it for 0.11, any objections to a 0.12 closely
following when these bits are ready?
I prefer the sound of closely after 0.11. I remember reading the HAL
guide on a bus a while ago -- what you speak of wouldn't be that hard,
would it?
Post by John Carr
* Simplifying the installation process, significantly.
Helping main distros get everything packaged and the hal callout i
mentioned should do this.
Mmm, good point -- the automation could easily go in the packaging. This
would mean that it would be more seamless than if we tried to generalise
the automation across all distros. However, this would involve having a
super packaging-push -- this is a good thing however. What would be
needed -- Debian, Ubuntu, Fedora, openSUSE, originally I think.
Post by John Carr
I'd like to see odccm be per device if its possible. And use HAL to
close each odccm when its own device is removed.. Any device
properties should be stashed in HAL rather than apps having to talk to
odccm. It seems a large chunk of odccm is boilerplate :-(
Personally I don't really see the point in supporting multiple devices
in odccm -- about 1 in 100 users need it, and I can't imagine it taking
next-to-no time to implement too.
Post by John Carr
In terms of supporting device passwords, blackberry also works in a
similar way and i'm pushing for some freedesktop-ish hook for storing
passwords in the keyring so that they can be automatically unlocked -
where we share as much as possible with barry (which is effectively
the synce of blackberry)
Can you expand on this please? What keyring? Blackberry works in what
similar way -- is this having the password-entry on the device?
Post by John Carr
There is no "modern" way to sync 2003 devices. You seem to have to use
ancient programs like a pre-opensync version of multisync. About 1 in
5 #synce requests is WM2003 related... That was a guess. Enough for it
to bother me that we don't offer support any more :P
So you think we should stop releasing specific WM2003 modules too
(synce-serial)?
Post by John Carr
I presume vdcccm won't support WM6? It also doesn't work with
sync-engine. Unfortunately dropping it hurts KDE users, who often ask
about RAKI. I have no idea what exactly that is, but seems not to work
with odccm. Yet. I am strongly in favor of having just one *dccm.
Either RAKI support in odccm or another standalone proggy, or vdccm
needs to be extended for WM6 and needs to be made to work with
sync-engine?
No I don't think vdccm does work with WM6. You bring up RAKI, but
remember that isn't a proper SynCE module now -- it was not released
with 0.10.0.

Thanks,
--
Jonny Lamb, UK ***@jonnylamb.com
http://jonnylamb.com GPG: 0x2E039402
John Carr
2007-12-05 17:30:28 UTC
Permalink
Post by Jonny Lamb
Post by John Carr
* Mess with wbxml. I have some basic pure python wbxml that we could
think about using, but i'm almost ashamed to admit it right now - not
really had time for it and code is a messy port of some PHP
Is that based on the PHP-based Exchange/Activesync server/application
that I was linked to from #synce? I definitely think this is important,
but perhaps not enough to work on before 0.11..
z-push is the PHP app of which I speak.
Post by Jonny Lamb
Post by John Carr
* dhcp-ifies a device
* starts odccm with the ips that dhcp sorted out (if not running)
* starts sync-engine (if not running)
If this doesn't make it for 0.11, any objections to a 0.12 closely
following when these bits are ready?
I prefer the sound of closely after 0.11. I remember reading the HAL
guide on a bus a while ago -- what you speak of wouldn't be that hard,
would it?
Right. This is theoretically quite easy. It would likely explode if a
user plugged 2 devices in at once, but if we don't care about that for
0.12 then fairy nuff.
Post by Jonny Lamb
Post by John Carr
* Simplifying the installation process, significantly.
Helping main distros get everything packaged and the hal callout i
mentioned should do this.
Mmm, good point -- the automation could easily go in the packaging. This
would mean that it would be more seamless than if we tried to generalise
the automation across all distros. However, this would involve having a
super packaging-push -- this is a good thing however. What would be
needed -- Debian, Ubuntu, Fedora, openSUSE, originally I think.
And Gentoo needs its ebuilds. Gentoo and Ubuntu are getting the most
users in #synce right now.
Post by Jonny Lamb
Post by John Carr
I'd like to see odccm be per device if its possible. And use HAL to
close each odccm when its own device is removed.. Any device
properties should be stashed in HAL rather than apps having to talk to
odccm. It seems a large chunk of odccm is boilerplate :-(
Personally I don't really see the point in supporting multiple devices
in odccm -- about 1 in 100 users need it, and I can't imagine it taking
next-to-no time to implement too.
Yay. I like that answer.
Post by Jonny Lamb
Post by John Carr
In terms of supporting device passwords, blackberry also works in a
similar way and i'm pushing for some freedesktop-ish hook for storing
passwords in the keyring so that they can be automatically unlocked -
where we share as much as possible with barry (which is effectively
the synce of blackberry)
Can you expand on this please? What keyring? Blackberry works in what
similar way -- is this having the password-entry on the device?
Right. The unlocking of password protected ness. The same way in which
you plug in a LUKS encrypted volume and are prompted for a password,
we will prompt you for a password and optionally story it in the
GNOME/KDE keyring (does KDE have one?) and then auto-unlock it in
future.
Post by Jonny Lamb
Post by John Carr
There is no "modern" way to sync 2003 devices. You seem to have to use
ancient programs like a pre-opensync version of multisync. About 1 in
5 #synce requests is WM2003 related... That was a guess. Enough for it
to bother me that we don't offer support any more :P
So you think we should stop releasing specific WM2003 modules too
(synce-serial)?
I was proposing we pray to jagow for sync-engine/2003 goodness...
Post by Jonny Lamb
Post by John Carr
I presume vdcccm won't support WM6? It also doesn't work with
sync-engine. Unfortunately dropping it hurts KDE users, who often ask
about RAKI. I have no idea what exactly that is, but seems not to work
with odccm. Yet. I am strongly in favor of having just one *dccm.
Either RAKI support in odccm or another standalone proggy, or vdccm
needs to be extended for WM6 and needs to be made to work with
sync-engine?
No I don't think vdccm does work with WM6. You bring up RAKI, but
remember that isn't a proper SynCE module now -- it was not released
with 0.10.0.
Ahh good point. RAKI was mentioned a lot when I tried to get people
running odccm in #synce is all. I'll make a note that is deprecated...

John
Jonny Lamb
2007-12-05 17:41:55 UTC
Permalink
Post by John Carr
z-push is the PHP app of which I speak.
Coolio. Any chance you could shove your python you've written up
somewhere? How much have you implemented? Looking at the PHP, it doesn't
look as if it'd take too long to sort that out.
Post by John Carr
And Gentoo needs its ebuilds. Gentoo and Ubuntu are getting the most
users in #synce right now.
Oops, I forgot about Gentoo. Well, Debian(/Ubuntu) and Gentoo are the
best prepared already though. We'd need some Fedora/openSUSE packagers
to help out. I hear openSUSE has packaging days, or something like
that..
Post by John Carr
Right. The unlocking of password protected ness. The same way in which
you plug in a LUKS encrypted volume and are prompted for a password,
we will prompt you for a password and optionally story it in the
GNOME/KDE keyring (does KDE have one?) and then auto-unlock it in
future.
Oh I see. The thing is, with WM6 the password is prompted for on the
device, and not the computer. It then sends an "authenticated", or "not
authenticated" signal. This obviously makes it impossible to store the
password, but that's really not our problem. I saw some API discussion
of gnome-keyring on d-d-l recently. It looks like a tremendously easy
task to achieve!
Post by John Carr
Post by Jonny Lamb
So you think we should stop releasing specific WM2003 modules too
(synce-serial)?
I was proposing we pray to jagow for sync-engine/2003 goodness...
Ah okay, that's cool! Well, when/if he has time/the will! :-)

Regards,
--
Jonny Lamb, UK ***@jonnylamb.com
http://jonnylamb.com GPG: 0x2E039402
Mark Ellis
2007-12-05 21:38:10 UTC
Permalink
Post by Jonny Lamb
Post by John Carr
Right. The unlocking of password protected ness. The same way in which
you plug in a LUKS encrypted volume and are prompted for a password,
we will prompt you for a password and optionally story it in the
GNOME/KDE keyring (does KDE have one?) and then auto-unlock it in
future.
Oh I see. The thing is, with WM6 the password is prompted for on the
device, and not the computer. It then sends an "authenticated", or "not
authenticated" signal. This obviously makes it impossible to store the
password, but that's really not our problem. I saw some API discussion
of gnome-keyring on d-d-l recently. It looks like a tremendously easy
task to achieve!
Ah that's interesting, nice to know how it works for future reference.
The gnome-keyring API is simplicity itself.
Post by Jonny Lamb
Post by John Carr
Post by Jonny Lamb
So you think we should stop releasing specific WM2003 modules too
(synce-serial)?
Definitely not.
Post by Jonny Lamb
Post by John Carr
I was proposing we pray to jagow for sync-engine/2003 goodness...
Ah okay, that's cool! Well, when/if he has time/the will! :-)
Sending positive waves to jagow.....

Mark
Dr J A Gow
2007-12-05 17:52:50 UTC
Permalink
Post by John Carr
I was proposing we pray to jagow for sync-engine/2003 goodness...
Your prayers are being answered..... :)

It won't get into the next release, but my preliminary investigations
have indicated that we should be able to make it happen. Some of the
changes to the sync-engine core that I am working on at the moment are
to facilitate the addition of code that will be able to use an RRA
backend for PIM syncing.
Post by John Carr
Post by Jonny Lamb
No I don't think vdccm does work with WM6. You bring up RAKI, but
remember that isn't a proper SynCE module now -- it was not released
with 0.10.0.
I'm working on a nice little GUI that will communicate with a running
sync-engine via d-bus. It's in concept stages at the moment so all
suggestions welcome. I am thinking it could look a little like
ActiveSync on steroids.... :) - providing a nice interface for both
partnership manipulation and OpenSync respectively to give users one
place to go to set up syncing. Watch this space.....


John.
John Carr
2007-12-05 20:09:05 UTC
Permalink
Hi John
Post by Dr J A Gow
I'm working on a nice little GUI that will communicate with a running
sync-engine via d-bus. It's in concept stages at the moment so all
suggestions welcome. I am thinking it could look a little like
ActiveSync on steroids.... :) - providing a nice interface for both
partnership manipulation and OpenSync respectively to give users one
place to go to set up syncing. Watch this space.....
Can we discuss this on IRC? Or perhaps SynCE Meet UK 07 :) I'm
hesitant to go Conduit! Conduit! Conduit! but the things like OpenSync
and Synce partnership manipulation sounds like it will overlap on the
stuff i'm working on for Conduit / Ubuntu "Sync that just works"...

We are in need of someone to help with the Konduit (KDE) UI for our
dbus sync daemon, and a fresh pair of eyes to help us beat the cross
platform bits in to shape would be great too..

If you are in theory interested i will dig out propaganda on the
vision and such, though it is quite vast in scope so you have a blue
pill/red pill moment first :-)

John
Dr J A Gow
2007-12-05 22:52:42 UTC
Permalink
Hi,
Post by John Carr
Hi John
Post by Dr J A Gow
I'm working on a nice little GUI that will communicate with a running
sync-engine via d-bus. It's in concept stages at the moment so all
suggestions welcome. I am thinking it could look a little like
ActiveSync on steroids.... :) - providing a nice interface for both
partnership manipulation and OpenSync respectively to give users one
place to go to set up syncing. Watch this space.....
Can we discuss this on IRC? Or perhaps SynCE Meet UK 07 :) I'm
hesitant to go Conduit! Conduit! Conduit! but the things like OpenSync
and Synce partnership manipulation sounds like it will overlap on the
stuff i'm working on for Conduit / Ubuntu "Sync that just works"...
We are in need of someone to help with the Konduit (KDE) UI for our
dbus sync daemon, and a fresh pair of eyes to help us beat the cross
platform bits in to shape would be great too..
This is probably a better idea than me trying to reinvent the wheel.
What concerns me though is just how it will impact users. It seems, at
least through talking with a colleague at work whom I managed to convert
to Linux a year ago that SynCE as it stands is a royal pig to install -
and I would have to agree with him. Not only that, but after having to
get the latest SVN releases to start it up first requires the usual
compilation and installation, then odccm to be run as root, then
sync-engine to be started as a user, then partnerships to be made, then
OpenSync to compile/install/configure before you can actually just run a
sync!

I thought that a little, simple, ActiveSync-like GUI that resides in the
system tray would make life a bit easier, if not in the install then in
the configuration phase.

Conduit is a brilliant concept and looks very good, at least from the
video. But how 'useable' in a 'dummies guide' type of way is it? Is it
straightforward to install and configure? Will it alienate kde
users? :-)

What I am really asking is how far away is Conduit from being workable
from a _user's_ perspective? If not too far, then I am definitely
interested in this route. If it is fairly distant, then perhaps we need
at least an interim solution to make SynCE palatable to the less
developer-minded user.
Post by John Carr
If you are in theory interested i will dig out propaganda on the
vision and such, though it is quite vast in scope so you have a blue
pill/red pill moment first :-)
I can't remember which pill was which - aw hell, whichever one is
stronger than the lousy coffee they serve at my university....

In theory, yes I am interested. Let me get these sync-engine
enhancements out of the way and then we can discuss it in more detail.
Once I have committed the sync-engine stuff I have to work on a couple
of other things, but should be able to get back to SynCE stuff after
Christmas.


John.
John Carr
2007-12-06 22:01:05 UTC
Permalink
I promised sales pitch, here it is :-)
Post by Dr J A Gow
What concerns me though is just how it will impact users. It seems, at
least through talking with a colleague at work whom I managed to convert
to Linux a year ago that SynCE as it stands is a royal pig to install -
and I would have to agree with him.
I think I remember talking to this user on IRC. Ask him if he
remembers Jc2k and say hi if he does.
Post by Dr J A Gow
Not only that, but after having to
get the latest SVN releases to start it up first requires the usual
compilation and installation, then odccm to be run as root, then
sync-engine to be started as a user, then partnerships to be made, then
OpenSync to compile/install/configure before you can actually just run a
sync!
Hopefully the odccm and sync-engine issues can be sorted out with the
HAL stuff. It looks like Mark might have a little bit of interest in
the *dccm HAL part at least. Good packaging, which we have pretty much
got for Gentoo/Debian/Ubuntu erase the installation woes.
Post by Dr J A Gow
I thought that a little, simple, ActiveSync-like GUI that resides in the
system tray would make life a bit easier, if not in the install then in
the configuration phase.
I'm hoping that conduit will remove most of the configuration that
currently exists. The only thing left will be partnerships, which we
can be handle with a combination of standalone tools and automatically
creating a partnership for conduit/opensync...
Post by Dr J A Gow
Conduit is a brilliant concept and looks very good, at least from the
video. But how 'useable' in a 'dummies guide' type of way is it? Is it
straightforward to install and configure? Will it alienate kde
users? :-)
One of the dbus util scripts we will ship in time for next ubuntu will
automatically detect any compatible device as you plug it in and ask
you where you want to sync it. We also have a few GUI alternatives in
the pipe works that present the information in different ways. I also
plan to steal the IA/UI expert at work for a bit (Francois Jordan).
His main area is the web but his thoughts on the desktop and its
behavior are very insightful.

It's a pure python app and needs a ./autogen.sh && make && make
install. It is packaged for a few distros and will be a default
install in Foresight and possibly Ubuntu Hardy+1.

The core parts of it run without GTK, but we need someone to step up
and make a Qt based front end for the dbus. Otherwise, yes. It would
alienate them.
Post by Dr J A Gow
What I am really asking is how far away is Conduit from being workable
from a _user's_ perspective? If not too far, then I am definitely
interested in this route. If it is fairly distant, then perhaps we need
at least an interim solution to make SynCE palatable to the less
developer-minded user.
We are aiming to showcase all the fancy desktop integration, hal
integration and other sync stuff at Linux Conf AU in January and
release some cool toys in time for Hardy Universe, if not sooner.
Post by Dr J A Gow
Post by John Carr
If you are in theory interested i will dig out propaganda on the
vision and such, though it is quite vast in scope so you have a blue
pill/red pill moment first :-)
I can't remember which pill was which - aw hell, whichever one is
stronger than the lousy coffee they serve at my university....
Take them both together and see what happens?
Post by Dr J A Gow
In theory, yes I am interested. Let me get these sync-engine
enhancements out of the way and then we can discuss it in more detail.
Once I have committed the sync-engine stuff I have to work on a couple
of other things, but should be able to get back to SynCE stuff after
Christmas.
Excellent, by the time you are back there should be something to show
rather than just big words :-)

John
Ochal Christophe
2007-12-08 13:44:32 UTC
Permalink
Post by Dr J A Gow
Post by John Carr
I was proposing we pray to jagow for sync-engine/2003 goodness...
Your prayers are being answered..... :)
Yaay!
Post by Dr J A Gow
It won't get into the next release, but my preliminary investigations
have indicated that we should be able to make it happen. Some of the
changes to the sync-engine core that I am working on at the moment are
to facilitate the addition of code that will be able to use an RRA
backend for PIM syncing.
Sounds great, as far as i can tell, most issue's with syncing WM2k3
devices comes from multisync not properly mapping the different items to
their proper counterparts on the other backends.

If you need beta/alfa testers, let me know.
Post by Dr J A Gow
Post by John Carr
Post by Jonny Lamb
No I don't think vdccm does work with WM6. You bring up RAKI, but
remember that isn't a proper SynCE module now -- it was not released
with 0.10.0.
I'm working on a nice little GUI that will communicate with a running
sync-engine via d-bus. It's in concept stages at the moment so all
suggestions welcome. I am thinking it could look a little like
ActiveSync on steroids.... :) - providing a nice interface for both
partnership manipulation and OpenSync respectively to give users one
place to go to set up syncing. Watch this
A beefed up version of synce-trayicon for gnome?
John Carr
2007-12-08 14:41:30 UTC
Permalink
Post by Ochal Christophe
Post by Dr J A Gow
It won't get into the next release, but my preliminary investigations
have indicated that we should be able to make it happen. Some of the
changes to the sync-engine core that I am working on at the moment are
to facilitate the addition of code that will be able to use an RRA
backend for PIM syncing.
Sounds great, as far as i can tell, most issue's with syncing WM2k3
devices comes from multisync not properly mapping the different items to
their proper counterparts on the other backends.
Another problem of course is that multisync long since died.
Post by Ochal Christophe
Post by Dr J A Gow
I'm working on a nice little GUI that will communicate with a running
sync-engine via d-bus. It's in concept stages at the moment so all
suggestions welcome. I am thinking it could look a little like
ActiveSync on steroids.... :) - providing a nice interface for both
partnership manipulation and OpenSync respectively to give users one
place to go to set up syncing. Watch this
A beefed up version of synce-trayicon for gnome?
He's a KDE fellow so I doubt that somewhat ;) Anyway I'm hoping John
will work with Conduit to help improve infrastructure and KDE support
instead... :D
Ochal Christophe
2007-12-08 13:34:52 UTC
Permalink
Post by Jonny Lamb
Post by John Carr
* Mess with wbxml. I have some basic pure python wbxml that we could
think about using, but i'm almost ashamed to admit it right now - not
really had time for it and code is a messy port of some PHP
Is that based on the PHP-based Exchange/Activesync server/application
that I was linked to from #synce? I definitely think this is important,
but perhaps not enough to work on before 0.11..
Do you have any more info on this? What php-based application are you
refurring to?
Post by Jonny Lamb
Post by John Carr
There is no "modern" way to sync 2003 devices. You seem to have to use
ancient programs like a pre-opensync version of multisync. About 1 in
5 #synce requests is WM2003 related... That was a guess. Enough for it
to bother me that we don't offer support any more :P
So you think we should stop releasing specific WM2003 modules too
(synce-serial)?
What exactly are the differences in syncing between WM2003 & WM5+? There
are still alot of WM2003 devices out there (i'm one of them ;)) that
work perfectly, dropping support of these seems premature, if i may say
so.
Mark Ellis
2007-12-05 21:30:07 UTC
Permalink
Post by John Carr
Lo all
Hi everyone.
A fairly long email with some various thoughts on several things. This
is meant to spark up discussion, so please do reply!
0.11
====
I think this needs to be released pretty soon. However, there are some
* Documentation -- yes this is the obvious one. Nothing really to say
about this.
I tried to start discussion about this earlier - mainly the best way
to structure the new wiki stuff and specifically how to deal with
distrubtuion specific bits without the duplication getting crazy.
At the moment, the docs are getting sooooo out of date a comprehensive
text file would be an improvement :) Seriously, I think we shouldn't get
overambitious, anything in whatever format would be good.
Post by John Carr
* Various fixes -- known bugs in the software that don't require a
whole new rewrite should really be fixed before the
release. Please
can you all reply with problems that spring to mind when I speak
about this, so I can keep track of the progress.
Rather a general "what needs to be done" list. Please do reply with
specifics! I suppose I'm suggesting we put in a freeze now and
concentrate on bugs, for the release.
* Data loss bug on WM6 phones when partnership is deleted - jagow is
close on that
* Mess with wbxml. I have some basic pure python wbxml that we could
think about using, but i'm almost ashamed to admit it right now - not
really had time for it and code is a messy port of some PHP
Not too up to date on PIM post WM2003 syncing, but it looks like John is
on a mission with it, and more power to him. What exactly is the deal
with wbxml again ?
Post by John Carr
* dhcp-ifies a device
* starts odccm with the ips that dhcp sorted out (if not running)
* starts sync-engine (if not running)
This stuff, while cool, I definitely see as low priority. The connection
infrastructure actually works. Of course if anyone feels the need to
play then that's up to them.
Post by John Carr
If this doesn't make it for 0.11, any objections to a 0.12 closely
following when these bits are ready?
0.10.0 to 0.11 (There's no point in an extra ".0" in "0.11" as there's
not going to be a "0.11.1" -- "0.10.0" was perhaps a little optimistic!)
isn't going to be the biggest update ever, but there are several nice
* Samsung SC* phones fixed with usb-rndis-lite.
* odccm now supports legacy devices.
* WM6 support.
* Various other fixes in SyncEngine.
Again, please fill the gaps here.
I think a new release will be very good for the project. It will provide
milestones that will be acceptable and doable for developers. It will
show SynCE as still being active and the new docs will make the project
more usable. The docs are currently what is stopping me pursuing
actually getting packages into Debian (and then perhaps Ubuntu), so that
would be started again.
I agree here, we need to release or users give up from lack of progress,
or get lost trying to build from svn. We've had a ton of minor fixes as
well, apart from the headlines above.
Post by John Carr
Further goals
=============
After 0.11 there will be some other features and fixes that will be
* Simplifying the installation process, significantly.
Helping main distros get everything packaged and the hal callout i
mentioned should do this.
I'd like to see odccm be per device if its possible. And use HAL to
close each odccm when its own device is removed.. Any device
properties should be stashed in HAL rather than apps having to talk to
odccm. It seems a large chunk of odccm is boilerplate :-(
As above, sounds like a nice idea, but should definitely be low
priority.
Post by John Carr
Other talking points
====================
vdccm: It seems to me that the only advantage of vdccm is its multiple
device support. Therefore, I am suggesting dropping vdccm as a proper
SynCE module. I'm not saying it should be deleted from SVN, but just
left out of releases. Thoughts?
I presume vdcccm won't support WM6? It also doesn't work with
sync-engine. Unfortunately dropping it hurts KDE users, who often ask
about RAKI. I have no idea what exactly that is, but seems not to work
with odccm. Yet. I am strongly in favor of having just one *dccm.
Either RAKI support in odccm or another standalone proggy, or vdccm
needs to be extended for WM6 and needs to be made to work with
sync-engine?
When we talk about multi device in vdccm, are we talking WM5 or
earlier ? I get the idea we are talking older devices, and odccm will
probably do this as well.

I am not a raki expert, but from the little I have been through it
shouldn't be too hard to move to odccm. Raki receives events via a
control socket in ~/.synce from vdccm, essentially the same events come
from odccm via dbus. Don't look at me for that, I can read C++ fine but
writing it is something else.
Post by John Carr
UK meetup: There are a few of us in the UK (myself, John Carr, J. A.
Gow, Mark Ellis, more?) -- John Carr and myself have spoken about
meeting up but I've been tremendously busy this term starting uni and
all that. Would anybody be interested in this?
Meeting ++;
Though not sure where :-)
Could be fun.

Mark
John Carr
2007-12-06 07:09:04 UTC
Permalink
Post by Mark Ellis
Post by John Carr
Lo all
I tried to start discussion about this earlier - mainly the best way
to structure the new wiki stuff and specifically how to deal with
distrubtuion specific bits without the duplication getting crazy.
At the moment, the docs are getting sooooo out of date a comprehensive
text file would be an improvement :) Seriously, I think we shouldn't get
overambitious, anything in whatever format would be good.
Maybe I was just telling myself that because after answering the same
question on #synce for the 5th time each day the though of having to
write docs as well makes me want to poke my eyes out..
Post by Mark Ellis
Post by John Carr
* Mess with wbxml. I have some basic pure python wbxml that we could
think about using, but i'm almost ashamed to admit it right now - not
really had time for it and code is a messy port of some PHP
Not too up to date on PIM post WM2003 syncing, but it looks like John is
on a mission with it, and more power to him. What exactly is the deal
with wbxml again ?
We has Wbxml patch that makes WM5 syncing possible. Upstream seems
dead. We need to get our patch packaged everywhere, or the
installation is going to remain awkward for new users. Alternative is
rolling our own pywbxml. We have a starter on this, which i ported
from z-push. I have one (tiny) passing test so far... *chuckles*.
Post by Mark Ellis
Post by John Carr
* dhcp-ifies a device
* starts odccm with the ips that dhcp sorted out (if not running)
* starts sync-engine (if not running)
This stuff, while cool, I definitely see as low priority. The connection
infrastructure actually works. Of course if anyone feels the need to
play then that's up to them.
It's a priority for Ubuntu's sync spec. It's a priority for Conduits
talk/demo at the end of January. It will be done, I was just hoping to
be transparent and get ideas from fellow devs, create inspiration
etc...
Post by Mark Ellis
I agree here, we need to release or users give up from lack of progress,
or get lost trying to build from svn. We've had a ton of minor fixes as
well, apart from the headlines above.
To be honest, the lack of roadmap and other such vital signs had me
convinced we were in maintenance mode...

John
David Eriksson
2007-12-06 08:05:21 UTC
Permalink
Post by John Carr
Post by Mark Ellis
I agree here, we need to release or users give up from lack of progress,
or get lost trying to build from svn. We've had a ton of minor fixes as
well, apart from the headlines above.
To be honest, the lack of roadmap and other such vital signs had me
convinced we were in maintenance mode...
Sorry for being really lousy at providing a vision and a roadmap for SynCE!

Maybe we can work something out together? Because you're the ones doing
the work!

I have probably never written down my vision properly, but from the top of
my head it is that:

Any user with one or more Windows Mobile devices can install a
distribution-provided (meta-)package on her Linux system, connect each
device using USB or Bluetooth, and then browse files, install applications
and synchronize contacts, calendar and tasks with her OpenSync-compatible
PIM application of choice.

What roadmap do you suggest for this? Some points I consider important:

o Get kernel stuff into mainstream kernel
o Get the latest userland stuff into major distributions
o HAL integration (I can show some MidaSync code for this.)
o Bluetooth support (I can show some MidaSync code for this.)
o GVFS support
(http://fosswire.com/2007/11/25/goodbye-gnomevfs-hello-giogvfs/)
o Revive KDE integration (but the currently active developers are GNOME
users, IIRC)

How about a 6-monthly release schedule aligned suitably with GNOME's and
Ubuntu's?

And last but not least: If anyone wants to step forward and drive this
project forward more actively than me, drop me a mail! :-)


Best regards,

David
John Carr
2007-12-06 10:08:56 UTC
Permalink
Post by David Eriksson
Post by John Carr
To be honest, the lack of roadmap and other such vital signs had me
convinced we were in maintenance mode...
Sorry for being really lousy at providing a vision and a roadmap for SynCE!
We still love you <3
Post by David Eriksson
Any user with one or more Windows Mobile devices can install a
distribution-provided (meta-)package on her Linux system, connect each
device using USB or Bluetooth, and then browse files, install applications
and synchronize contacts, calendar and tasks with her OpenSync-compatible
PIM application of choice.
http://www.synce.org/moin/FrontPage
Post by David Eriksson
o Get kernel stuff into mainstream kernel
o Get the latest userland stuff into major distributions
I'll take care of any Ubuntu issues, but hopefully that will just be a
straight sync out of jonnylambs Debian packages.
Post by David Eriksson
o HAL integration (I can show some MidaSync code for this.)
Yes please
Post by David Eriksson
o Bluetooth support (I can show some MidaSync code for this.)
Yes please
Post by David Eriksson
o GVFS support
(http://fosswire.com/2007/11/25/goodbye-gnomevfs-hello-giogvfs/)
o Revive KDE integration (but the currently active developers are GNOME
users, IIRC)
How about a 6-monthly release schedule aligned suitably with GNOME's and
Ubuntu's?
I like this, but would want to release soon and release again in time
for 8.04 so that the HAL stuff i'm looking at can be in next ubuntu
release.
Post by David Eriksson
And last but not least: If anyone wants to step forward and drive this
project forward more actively than me, drop me a mail! :-)
I think jonnylamb is doing that with his original e-mail :-P
David Eriksson
2007-12-06 11:38:31 UTC
Permalink
Post by John Carr
Post by David Eriksson
Post by John Carr
To be honest, the lack of roadmap and other such vital signs had me
convinced we were in maintenance mode...
Sorry for being really lousy at providing a vision and a roadmap for SynCE!
We still love you <3
Post by David Eriksson
Any user with one or more Windows Mobile devices can install a
distribution-provided (meta-)package on her Linux system, connect each
device using USB or Bluetooth, and then browse files, install
applications
and synchronize contacts, calendar and tasks with her
OpenSync-compatible
PIM application of choice.
http://www.synce.org/moin/FrontPage
:-)
Post by John Carr
Post by David Eriksson
o Get kernel stuff into mainstream kernel
o Get the latest userland stuff into major distributions
I'll take care of any Ubuntu issues, but hopefully that will just be a
straight sync out of jonnylambs Debian packages.
Post by David Eriksson
o HAL integration (I can show some MidaSync code for this.)
Yes please
With midasync.fdi in place somewhere in /etc/hal/fdi/ or
/usr/share/hal/fdi/ the midasync-hal code can identify a pre-WM5 device
and its serial port (ttyUSB-something) for further processing with
CLIENT/CLIENTSERVER handshake and PPP connection.

http://synce.sourceforge.net/tmp/midasync.fdi.gz (MIT license)
http://synce.sourceforge.net/tmp/midasync-hal.tar.gz (MIT license)
Post by John Carr
Post by David Eriksson
o Bluetooth support (I can show some MidaSync code for this.)
Yes please
The midasync-bluetooth code publishes a Bluetooth serial port called
MidaSync and handles incoming connections. A serial port is created for
further processing with CLIENT/CLIENTSERVER handshake and PPP connection.

http://synce.sourceforge.net/tmp/midasync-bluetooth.tar.gz (MIT license)
Post by John Carr
Post by David Eriksson
o GVFS support
(http://fosswire.com/2007/11/25/goodbye-gnomevfs-hello-giogvfs/)
o Revive KDE integration (but the currently active developers are GNOME
users, IIRC)
How about a 6-monthly release schedule aligned suitably with GNOME's and
Ubuntu's?
I like this, but would want to release soon and release again in time
for 8.04 so that the HAL stuff i'm looking at can be in next ubuntu
release.
Yes, we need a release Real Soon Now, and then it would be nice to have a
new release for inclusion in the next Ubuntu.
Post by John Carr
Post by David Eriksson
And last but not least: If anyone wants to step forward and drive this
project forward more actively than me, drop me a mail! :-)
I think jonnylamb is doing that with his original e-mail :-P
You're right! A shame he spends so much time studying... ;-)


Cheers,

David
Ochal Christophe
2007-12-08 13:28:39 UTC
Permalink
Post by John Carr
Lo all
Hi everyone.
A fairly long email with some various thoughts on several things. This
is meant to spark up discussion, so please do reply!
0.11
====
I think this needs to be released pretty soon. However, there are some
* Documentation -- yes this is the obvious one. Nothing really to say
about this.
I tried to start discussion about this earlier - mainly the best way
to structure the new wiki stuff and specifically how to deal with
distrubtuion specific bits without the duplication getting crazy.
The ideal way i think is to have a small team, of 2 or 3 individuals
working on the documentation, a small team working closely together on
this should be able to bring the documentation up to date in no time,
even a one man team should be able to do it in little time.
Post by John Carr
* Various fixes -- known bugs in the software that don't require a
whole new rewrite should really be fixed before the
release. Please
can you all reply with problems that spring to mind when I speak
about this, so I can keep track of the progress.
Rather a general "what needs to be done" list. Please do reply with
specifics! I suppose I'm suggesting we put in a freeze now and
concentrate on bugs, for the release.
* Data loss bug on WM6 phones when partnership is deleted - jagow is
close on that
* Mess with wbxml. I have some basic pure python wbxml that we could
think about using, but i'm almost ashamed to admit it right now - not
really had time for it and code is a messy port of some PHP
* dhcp-ifies a device
* starts odccm with the ips that dhcp sorted out (if not running)
* starts sync-engine (if not running)
If this doesn't make it for 0.11, any objections to a 0.12 closely
following when these bits are ready?
I like the HAL idea alot, but i don't know if HAL reacts to eg a
bluetooth device connecting to the PC
Post by John Carr
0.10.0 to 0.11 (There's no point in an extra ".0" in "0.11" as there's
not going to be a "0.11.1" -- "0.10.0" was perhaps a little optimistic!)
isn't going to be the biggest update ever, but there are several nice
* Samsung SC* phones fixed with usb-rndis-lite.
* odccm now supports legacy devices.
* WM6 support.
* Various other fixes in SyncEngine.
Again, please fill the gaps here.
I think a new release will be very good for the project. It will provide
milestones that will be acceptable and doable for developers. It will
show SynCE as still being active and the new docs will make the project
more usable. The docs are currently what is stopping me pursuing
actually getting packages into Debian (and then perhaps Ubuntu), so that
would be started again.
Have been in talks with Ubuntu (wrt Conduit and sync that "just works"
- you plug it in and it says "where sync to.. k thx bye") and its
likely that we'll see some support into pulling the latest and
greatest into the next release (probably more in terms of acceptance
rather than actual man hours)...
I wrote that initial draft, conduit seems like an excellent 'glue' to
tie synce and eg gnokii together.
Post by John Carr
Further goals
=============
After 0.11 there will be some other features and fixes that will be
* Simplifying the installation process, significantly.
Helping main distros get everything packaged and the hal callout i
mentioned should do this.
I'd like to see odccm be per device if its possible. And use HAL to
close each odccm when its own device is removed.. Any device
properties should be stashed in HAL rather than apps having to talk to
odccm. It seems a large chunk of odccm is boilerplate :-(
In terms of supporting device passwords, blackberry also works in a
similar way and i'm pushing for some freedesktop-ish hook for storing
passwords in the keyring so that they can be automatically unlocked -
where we share as much as possible with barry (which is effectively
the synce of blackberry)
Using keyrings sounds like a good idea.
Post by John Carr
* Removing the libwbxml dependency.
If you have any other ideas, please state them here. If the idea has not
previously been aired, please give some information about it.
There is no "modern" way to sync 2003 devices. You seem to have to use
ancient programs like a pre-opensync version of multisync. About 1 in
5 #synce requests is WM2003 related... That was a guess. Enough for it
to bother me that we don't offer support any more :P
You want to drop WM2003?
Post by John Carr
Other talking points
====================
vdccm: It seems to me that the only advantage of vdccm is its multiple
device support. Therefore, I am suggesting dropping vdccm as a proper
SynCE module. I'm not saying it should be deleted from SVN, but just
left out of releases. Thoughts?
I presume vdcccm won't support WM6? It also doesn't work with
sync-engine. Unfortunately dropping it hurts KDE users, who often ask
about RAKI. I have no idea what exactly that is, but seems not to work
with odccm. Yet. I am strongly in favor of having just one *dccm.
Either RAKI support in odccm or another standalone proggy, or vdccm
needs to be extended for WM6 and needs to be made to work with
sync-engine?
vdccm also works with the ancient multisync for wm2003 devices

With kind regards,
John Carr
2007-12-08 14:53:42 UTC
Permalink
Post by Ochal Christophe
Post by John Carr
I tried to start discussion about this earlier - mainly the best way
to structure the new wiki stuff and specifically how to deal with
distrubtuion specific bits without the duplication getting crazy.
The ideal way i think is to have a small team, of 2 or 3 individuals
working on the documentation, a small team working closely together on
this should be able to bring the documentation up to date in no time,
even a one man team should be able to do it in little time.
The documentation would have probably been written by now if someone
would have replied to my proposed structure.

My feeling was that myself and Jonnylamb should make the initial pass.
Mainly to get the structure right. We are also keen to moderate the
new wiki as the old one has errors... And looking at the "resources"
on ubuntuforums.org we are keen not to have just anyone writing things
on there - the "help" is often dangerous or just plain wrong.
Post by Ochal Christophe
I like the HAL idea alot, but i don't know if HAL reacts to eg a
bluetooth device connecting to the PC
There is a project underway somewhere to take care of that. "Not yet"
would be the response.
Post by Ochal Christophe
Post by John Carr
Have been in talks with Ubuntu (wrt Conduit and sync that "just works"
- you plug it in and it says "where sync to.. k thx bye") and its
likely that we'll see some support into pulling the latest and
greatest into the next release (probably more in terms of acceptance
rather than actual man hours)...
I wrote that initial draft, conduit seems like an excellent 'glue' to
tie synce and eg gnokii together.
Tis great to here acceptance (wrt conduit). Its taken a lot to get so
far, and some peoples attitudes just make you want to give in.
Post by Ochal Christophe
Post by John Carr
There is no "modern" way to sync 2003 devices. You seem to have to use
ancient programs like a pre-opensync version of multisync. About 1 in
5 #synce requests is WM2003 related... That was a guess. Enough for it
to bother me that we don't offer support any more :P
You want to drop WM2003?
Hope my reply got through! No, my desire was that jagow might be able
to resurrect the RRA stuff inside sync-engine.
Post by Ochal Christophe
Post by John Carr
I presume vdcccm won't support WM6? It also doesn't work with
sync-engine. Unfortunately dropping it hurts KDE users, who often ask
about RAKI. I have no idea what exactly that is, but seems not to work
with odccm. Yet. I am strongly in favor of having just one *dccm.
Either RAKI support in odccm or another standalone proggy, or vdccm
needs to be extended for WM6 and needs to be made to work with
sync-engine?
vdccm also works with the ancient multisync for wm2003 devices
With the work that jagow and mark are doing that won't matter - we can
have a nice working and modern opensync/sync-engine/odccm. Really
don't want to have to figure out and document years old releases of
things :-)
Ochal Christophe
2007-12-09 11:38:50 UTC
Permalink
Post by John Carr
Post by Ochal Christophe
The ideal way i think is to have a small team, of 2 or 3 individuals
working on the documentation, a small team working closely together on
this should be able to bring the documentation up to date in no time,
even a one man team should be able to do it in little time.
The documentation would have probably been written by now if someone
would have replied to my proposed structure.
My feeling was that myself and Jonnylamb should make the initial pass.
Mainly to get the structure right. We are also keen to moderate the
new wiki as the old one has errors... And looking at the "resources"
on ubuntuforums.org we are keen not to have just anyone writing things
on there - the "help" is often dangerous or just plain wrong.
I'll see if i can digg up that post of yours, it was prior to my arrival
on the ML.
Post by John Carr
Post by Ochal Christophe
I like the HAL idea alot, but i don't know if HAL reacts to eg a
bluetooth device connecting to the PC
There is a project underway somewhere to take care of that. "Not yet"
would be the response.
Cool.
Post by John Carr
Post by Ochal Christophe
Post by John Carr
Have been in talks with Ubuntu (wrt Conduit and sync that "just works"
- you plug it in and it says "where sync to.. k thx bye") and its
likely that we'll see some support into pulling the latest and
greatest into the next release (probably more in terms of acceptance
rather than actual man hours)...
I wrote that initial draft, conduit seems like an excellent 'glue' to
tie synce and eg gnokii together.
Tis great to here acceptance (wrt conduit). Its taken a lot to get so
far, and some peoples attitudes just make you want to give in.
Conduit is shaping up really nicely, definatly a project that's on my
radar ;)
Post by John Carr
Post by Ochal Christophe
Post by John Carr
There is no "modern" way to sync 2003 devices. You seem to have to use
ancient programs like a pre-opensync version of multisync. About 1 in
5 #synce requests is WM2003 related... That was a guess. Enough for it
to bother me that we don't offer support any more :P
You want to drop WM2003?
Hope my reply got through! No, my desire was that jagow might be able
to resurrect the RRA stuff inside sync-engine.
Yaay for Jagow! ^^
Post by John Carr
Post by Ochal Christophe
Post by John Carr
I presume vdcccm won't support WM6? It also doesn't work with
sync-engine. Unfortunately dropping it hurts KDE users, who often ask
about RAKI. I have no idea what exactly that is, but seems not to work
with odccm. Yet. I am strongly in favor of having just one *dccm.
Either RAKI support in odccm or another standalone proggy, or vdccm
needs to be extended for WM6 and needs to be made to work with
sync-engine?
vdccm also works with the ancient multisync for wm2003 devices
With the work that jagow and mark are doing that won't matter - we can
have a nice working and modern opensync/sync-engine/odccm. Really
don't want to have to figure out and document years old releases of
things :-)
So, no legacy section in the docs then? ;)
Mark Ellis
2007-12-10 15:36:23 UTC
Permalink
Post by John Carr
Post by Ochal Christophe
I like the HAL idea alot, but i don't know if HAL reacts to eg a
bluetooth device connecting to the PC
There is a project underway somewhere to take care of that. "Not yet"
would be the response.
Good, this was one of the "problem" areas I had thought of. Quick aside,
anyone tried a WM5 bluetooth connection in the current framework ? How
does it work.
Post by John Carr
Post by Ochal Christophe
Post by John Carr
Have been in talks with Ubuntu (wrt Conduit and sync that "just works"
- you plug it in and it says "where sync to.. k thx bye") and its
likely that we'll see some support into pulling the latest and
greatest into the next release (probably more in terms of acceptance
rather than actual man hours)...
I wrote that initial draft, conduit seems like an excellent 'glue' to
tie synce and eg gnokii together.
Tis great to here acceptance (wrt conduit). Its taken a lot to get so
far, and some peoples attitudes just make you want to give in.
Post by Ochal Christophe
Post by John Carr
There is no "modern" way to sync 2003 devices. You seem to have to use
ancient programs like a pre-opensync version of multisync. About 1 in
5 #synce requests is WM2003 related... That was a guess. Enough for it
to bother me that we don't offer support any more :P
Interesting, obviously I dont hang out on #synce, not nearly enough
time, but are these generally connection or sync based problems ? Again,
I would guess half the problems are due to having too many options with
with up to date guidance rather than being real bugs, but I'm guessing.
Post by John Carr
Post by Ochal Christophe
You want to drop WM2003?
Hope my reply got through! No, my desire was that jagow might be able
to resurrect the RRA stuff inside sync-engine.
Go jagow !
Post by John Carr
Post by Ochal Christophe
Post by John Carr
I presume vdcccm won't support WM6? It also doesn't work with
sync-engine. Unfortunately dropping it hurts KDE users, who often ask
about RAKI. I have no idea what exactly that is, but seems not to work
with odccm. Yet. I am strongly in favor of having just one *dccm.
Either RAKI support in odccm or another standalone proggy, or vdccm
needs to be extended for WM6 and needs to be made to work with
sync-engine?
vdccm with WM6, don't know, but would guess it works fine.

vdccm with sync-engine, don't know, have a pre WM5 device, go jagow !
Sorry John, no pressure :)

Raki support in odccm is not going to happen, it would be messy. odccm
support in Raki however, is very simple for anyone who can do dbus in C
++, if anyone can please step up, I'll tell you exactly what needs to be
done. I can do dbus but not C++. This will also be the case with
hal-dccm.

An alternative is a fake vdccm on top of odccm/hal-dccm, I can do this
when I clone myself :)
Post by John Carr
Post by Ochal Christophe
vdccm also works with the ancient multisync for wm2003 devices
wm2003 multisync works with any *dccm. Anything that uses pure rapi
calls should.
Post by John Carr
With the work that jagow and mark are doing that won't matter - we can
have a nice working and modern opensync/sync-engine/odccm. Really
don't want to have to figure out and document years old releases of
things :-)
Could be fun, people could read it to respond "you used to have to do
what !!!!" :)

Mark
Dr J A Gow
2007-12-05 17:45:43 UTC
Permalink
Post by Jonny Lamb
Hi everyone.
A fairly long email with some various thoughts on several things. This
is meant to spark up discussion, so please do reply!
0.11
====
I think this needs to be released pretty soon. However, there are some
* Documentation -- yes this is the obvious one. Nothing really to say
about this.
* Various fixes -- known bugs in the software that don't require a
whole new rewrite should really be fixed before the release. Please
can you all reply with problems that spring to mind when I speak
about this, so I can keep track of the progress.
Rather a general "what needs to be done" list. Please do reply with
specifics! I suppose I'm suggesting we put in a freeze now and
concentrate on bugs, for the release.
0.10.0 to 0.11 (There's no point in an extra ".0" in "0.11" as there's
not going to be a "0.11.1" -- "0.10.0" was perhaps a little optimistic!)
isn't going to be the biggest update ever, but there are several nice
* Samsung SC* phones fixed with usb-rndis-lite.
* odccm now supports legacy devices.
* WM6 support.
* Various other fixes in SyncEngine.
Again, please fill the gaps here.
I think a new release will be very good for the project. It will provide
milestones that will be acceptable and doable for developers. It will
show SynCE as still being active and the new docs will make the project
more usable. The docs are currently what is stopping me pursuing
actually getting packages into Debian (and then perhaps Ubuntu), so that
would be started again.
Further goals
=============
After 0.11 there will be some other features and fixes that will be
* Simplifying the installation process, significantly.
* Removing the libwbxml dependency.
If you have any other ideas, please state them here. If the idea has not
previously been aired, please give some information about it.
Other talking points
====================
vdccm: It seems to me that the only advantage of vdccm is its multiple
device support. Therefore, I am suggesting dropping vdccm as a proper
SynCE module. I'm not saying it should be deleted from SVN, but just
left out of releases. Thoughts?
ML moderator: I am currently looking for someone who will help out by
moderating the mailing lists. This basically takes two minutes every few
days or so and involves just filtering out spam from real mail. This
effort keeps the SynCE mailing lists spam-free. Email me if you are
interested in helping out, or would like to know more.
UK meetup: There are a few of us in the UK (myself, John Carr, J. A.
Gow, Mark Ellis, more?) -- John Carr and myself have spoken about
meeting up but I've been tremendously busy this term starting uni and
all that. Would anybody be interested in this?
I hope this is easy to read and is not too boring! :-)
Kind regards,
Hi,

I am working very heavily on sync-engine (literally every spare moment
at present) to considerably clean up the partnership code and fix a lot
of latent issues with it (and there are quite a few which may not have
shown up in general use yet), also to fix a couple of WM6 bugs and add
important features (already have DTPT working from within sync-engine
obviating the need for a seperate module). These are substantial
changes, improvements and fixes so it may be worth holding off on a
release until I can commit these in the next week or so.

Note I am testing these changes on a daily basis in my production
environment (either confident or stupid, I haven't worked out which
yet :-) and I don't really want to commit them until I can be sure they
work and aren't going to trash anything, so I am looking at a timescale
of about a week before they should be ready.

I'm trying to use as much available time as possible for actual coding
at the moment. I'll keep an eye on the bug tracker when possible but it
may speed things up if someone could be kind enough to batch up all the
current known sync-engine bugs or odd behaviour especially if not in the
tracker, and send it to me in one mail. I will try then to get fixes in
with the new code.

Regarding a UK meet: this sounds like an excellent idea!

John.
Jonny Lamb
2007-12-05 18:01:09 UTC
Permalink
Post by Dr J A Gow
I am working very heavily on sync-engine (literally every spare moment
at present) to considerably clean up the partnership code and fix a
lot of latent issues with it (and there are quite a few which may not
have shown up in general use yet), also to fix a couple of WM6 bugs
and add important features (already have DTPT working from within
sync-engine obviating the need for a seperate module).
That is great! Don't wear yourself out!
Post by Dr J A Gow
These are substantial changes, improvements and fixes so it may be
worth holding off on a release until I can commit these in the next
week or so.
I wasn't talking about a release in a week, more like within the next
month, but the earlier the better.
Post by Dr J A Gow
Note I am testing these changes on a daily basis in my production
environment (either confident or stupid, I haven't worked out which
yet :-) and I don't really want to commit them until I can be sure
they work and aren't going to trash anything, so I am looking at a
timescale of about a week before they should be ready.
Again, that's fine -- no rush. Take your time!
Post by Dr J A Gow
I'm trying to use as much available time as possible for actual coding
at the moment. I'll keep an eye on the bug tracker when possible but
it may speed things up if someone could be kind enough to batch up all
the current known sync-engine bugs or odd behaviour especially if not
in the tracker, and send it to me in one mail. I will try then to get
fixes in with the new code.
That's great!
Post by Dr J A Gow
Regarding a UK meet: this sounds like an excellent idea!
Sweet. Ping me on IRC next time you're online and we shall chat about
it.

Heh, short and sweet response!
--
Jonny Lamb, UK ***@jonnylamb.com
http://jonnylamb.com GPG: 0x2E039402
Ochal Christophe
2007-12-08 13:16:37 UTC
Permalink
Hi,
Post by Jonny Lamb
Hi everyone.
A fairly long email with some various thoughts on several things. This
is meant to spark up discussion, so please do reply!
0.11
====
I think this needs to be released pretty soon. However, there are some
* Documentation -- yes this is the obvious one. Nothing really to say
about this.
Like i offered several weeks ago, i am more then willing to take this
task upon me, all i need are some guidelines as to what system you want
to use for this. (PDF? Docbook? simple html?)

Also, i'll probably bug you guys every now & then when i need info on
the various parts ;)
Post by Jonny Lamb
* Various fixes -- known bugs in the software that don't require a
whole new rewrite should really be fixed before the release. Please
can you all reply with problems that spring to mind when I speak
about this, so I can keep track of the progress.
The only real problem i'm aware of is that support for pre-WM5 devices
is limited to say the least, i understand none of the developers have
these devices, but again, i offer my support in this area in away way i
can.
Post by Jonny Lamb
Rather a general "what needs to be done" list. Please do reply with
specifics! I suppose I'm suggesting we put in a freeze now and
concentrate on bugs, for the release.
The following things come to mind:
- Ease of use: as it is right now, synce isn't the most userfriendly
thing out there, improving the documentation here would improve the
situation alot.
- As i understand it, several things still require elevated rights, it
would be best if this could be avoided/reduced? Ignore this if this is
already done ;)
- Features: Syncing PIM, mail, browser favourites, folders, files, the
more things that can be synced consistently, the better, again, i am
unaware of the state of syncing with WM5+ devices
Post by Jonny Lamb
0.10.0 to 0.11 (There's no point in an extra ".0" in "0.11" as there's
not going to be a "0.11.1" -- "0.10.0" was perhaps a little optimistic!)
isn't going to be the biggest update ever, but there are several nice
* Samsung SC* phones fixed with usb-rndis-lite.
* odccm now supports legacy devices.
* WM6 support.
* Various other fixes in SyncEngine.
Again, please fill the gaps here.
I think a new release will be very good for the project. It will provide
milestones that will be acceptable and doable for developers. It will
show SynCE as still being active and the new docs will make the project
more usable. The docs are currently what is stopping me pursuing
actually getting packages into Debian (and then perhaps Ubuntu), so that
would be started again.
Seems like a good idea
Post by Jonny Lamb
Further goals
=============
After 0.11 there will be some other features and fixes that will be
* Simplifying the installation process, significantly.
* Removing the libwbxml dependency.
What are the current pitfalls in installation *EXCEPT* the
documentation? If feasable, why not do this now?
Post by Jonny Lamb
If you have any other ideas, please state them here. If the idea has not
previously been aired, please give some information about it.
Other talking points
====================
vdccm: It seems to me that the only advantage of vdccm is its multiple
device support. Therefore, I am suggesting dropping vdccm as a proper
SynCE module. I'm not saying it should be deleted from SVN, but just
left out of releases. Thoughts?
The current state, where there is dccm (that's depricated iirc?), vdccm
and odccm does add to the confusion, going ahead with only one of them
makes sense.

With kind regards,
Mark Ellis
2007-12-10 15:13:24 UTC
Permalink
Post by Ochal Christophe
The only real problem i'm aware of is that support for pre-WM5 devices
is limited to say the least, i understand none of the developers have
these devices, but again, i offer my support in this area in away way i
can.
Depends on your point of view, and for this point out a distinction that
I always make in my own little world, that of _connection_ and
_syncing_.

Pre WM5 devices connect just fine, using any kind of dccm you like. In
fact for multiple device support pre WM5 is your only (apparently) tried
and tested option.

As far as PIM syncing is concerned, I'm still happily going with the old
multisync on my WM2003 using librra. Obviously this isn't a long term
option, and I'd love to play with sync-engine, but it definitely still
works.
Post by Ochal Christophe
Post by Jonny Lamb
Rather a general "what needs to be done" list. Please do reply with
specifics! I suppose I'm suggesting we put in a freeze now and
concentrate on bugs, for the release.
- Ease of use: as it is right now, synce isn't the most userfriendly
thing out there, improving the documentation here would improve the
situation alot.
And we're developers, I dread to think what it must be like for anyone
else ! Actually I remember when I first arrived in synce world, it was
actually slightly more straight forward with my WM2003 because it was a
slightly more mature system and the docs were still relevant. A lot of
the current confusion is I believe due to there being no current
guidelines on just what you need for a particular device.
Post by Ochal Christophe
- As i understand it, several things still require elevated rights, it
would be best if this could be avoided/reduced? Ignore this if this is
already done ;)
The only thing I am aware of that requires elevated rights is the *dccm
for WM5, which requires a reserved IP port, 990, therefore odccm runs as
root. vdccm became suid when it supported WM5, and drops root
priviledges when it doesn't need them, but this is not as nice IMHO.
Post by Ochal Christophe
Post by Jonny Lamb
Further goals
=============
After 0.11 there will be some other features and fixes that will be
* Simplifying the installation process, significantly.
* Removing the libwbxml dependency.
What are the current pitfalls in installation *EXCEPT* the
documentation? If feasable, why not do this now?
Having put a lot more thought into hal-dccm, I think it may make at
least the connection side a lot simpler. You'll install the package and
it will just work, particularly since for preWM5 synce-serial will
basically have to become part of the dccm setup.
Post by Ochal Christophe
Post by Jonny Lamb
If you have any other ideas, please state them here. If the idea has not
previously been aired, please give some information about it.
Other talking points
====================
vdccm: It seems to me that the only advantage of vdccm is its multiple
device support. Therefore, I am suggesting dropping vdccm as a proper
SynCE module. I'm not saying it should be deleted from SVN, but just
left out of releases. Thoughts?
The current state, where there is dccm (that's depricated iirc?), vdccm
and odccm does add to the confusion, going ahead with only one of them
makes sense.
I've probably just depressed you mentioning hal-dccm then :)

Yes there are too many. dccm is deprecated and there is no point in
using it ever, vdccm can be dropped straight in its place. If the debian
packages weren't so old we probably wouldn't ever see it.

Mark
John Carr
2007-12-10 15:51:40 UTC
Permalink
Post by Mark Ellis
As far as PIM syncing is concerned, I'm still happily going with the old
multisync on my WM2003 using librra. Obviously this isn't a long term
option, and I'd love to play with sync-engine, but it definitely still
works.
I don't suppose you could document your setup. Just in brief if your
short on time. What versions of things and how you make it go? At the
moment i'm turning people away on IRC and saying "some day"...
Post by Mark Ellis
Having put a lot more thought into hal-dccm, I think it may make at
least the connection side a lot simpler. You'll install the package and
it will just work, particularly since for preWM5 synce-serial will
basically have to become part of the dccm setup.
The people at #opensync and ubuntu were happy that we detect WM2003
devices based on them using the ipaq driver, rather than duplicating
the product and vendor ids in an FDI...

Though I have to strongly vote for calling it odccm 0.11 / 0.12 OR
mdccm :-P - keeping it as a new version of odccm might reduce
confusion... ?

John
Mark Ellis
2007-12-10 16:25:28 UTC
Permalink
Post by John Carr
Post by Mark Ellis
As far as PIM syncing is concerned, I'm still happily going with the old
multisync on my WM2003 using librra. Obviously this isn't a long term
option, and I'd love to play with sync-engine, but it definitely still
works.
I don't suppose you could document your setup. Just in brief if your
short on time. What versions of things and how you make it go? At the
moment i'm turning people away on IRC and saying "some day"...
Debian packages
multisync 0.82-8+b4
synce-multisync-plugin 0.9.0-4

Can't remember the details of what I did, but from memory it wasn't too
tricky. Multisync has to be started after the device is connected, I'm
syncing WM2003 with evolution. Afraid I can't remember whether I created
a partnership with the command line first, I'll try and trawl my memory.
Post by John Carr
Post by Mark Ellis
Having put a lot more thought into hal-dccm, I think it may make at
least the connection side a lot simpler. You'll install the package and
it will just work, particularly since for preWM5 synce-serial will
basically have to become part of the dccm setup.
The people at #opensync and ubuntu were happy that we detect WM2003
devices based on them using the ipaq driver, rather than duplicating
the product and vendor ids in an FDI...
Cool, that would have been a pain.
Post by John Carr
Though I have to strongly vote for calling it odccm 0.11 / 0.12 OR
mdccm :-P - keeping it as a new version of odccm might reduce
confusion... ?
:) You old traditionalist....

Point taken. The infrastructure will be substantially different however.
Once I have more of a plan we'll see...

Mark
Scott Gifford
2007-12-12 07:35:34 UTC
Permalink
Jonny Lamb <***@jonnylamb.com> writes:

[...]
Post by Jonny Lamb
vdccm: It seems to me that the only advantage of vdccm is its multiple
device support. Therefore, I am suggesting dropping vdccm as a proper
SynCE module. I'm not saying it should be deleted from SVN, but just
left out of releases. Thoughts?
For those who need this it is a really important feature, and it would
be a shame to lose it to bitrot if vdccm were removed.

Is there a great deal involved in making odccm support multiple
devices?

----Scott.
Mark Ellis
2007-12-12 07:58:05 UTC
Permalink
Post by Scott Gifford
Post by Jonny Lamb
vdccm: It seems to me that the only advantage of vdccm is its multiple
device support. Therefore, I am suggesting dropping vdccm as a proper
SynCE module. I'm not saying it should be deleted from SVN, but just
left out of releases. Thoughts?
For those who need this it is a really important feature, and it would
be a shame to lose it to bitrot if vdccm were removed.
Is there a great deal involved in making odccm support multiple
devices?
----Scott.
Ah Scott, good timing, you just reminded me of something I had to do !

I took a look at your changes to synce-serial, good stuff, fiddled a bit
to get them into the current tree, and completely forgot to do anything
else. So I've just committed it. Haven't tried multiple devices because
I only have 1, but I don't see any reason why it shouldn't work, and
it's worth it just from the extra sophistication.

Anyone who wants to have a look but can't find it in svn, it's in
branches/legacy/serial. I would move it into trunk but want to see how
hal-dccm goes first.

Anyway, Scott, I'm assuming your question relates only to pre WM5
devices, yes ? In that case, theoretically, odccm should already support
multiple devices. Anyone want to be a guinea pig, try the new serial
scripts, give both vdccm and odccm a go and let us know.

Ta
Mark
Scott Gifford
2007-12-12 18:12:35 UTC
Permalink
Mark Ellis <***@ntlworld.com> writes:

[...]
Post by Mark Ellis
I took a look at your changes to synce-serial, good stuff, fiddled a bit
to get them into the current tree, and completely forgot to do anything
else. So I've just committed it. Haven't tried multiple devices because
I only have 1, but I don't see any reason why it shouldn't work, and
it's worth it just from the extra sophistication.
Fantastic, thanks!
Post by Mark Ellis
Anyway, Scott, I'm assuming your question relates only to pre WM5
devices, yes ? In that case, theoretically, odccm should already support
multiple devices. Anyone want to be a guinea pig, try the new serial
scripts, give both vdccm and odccm a go and let us know.
Well, those are the only ones I've used. I don't have access to my
pile of devices anymore, unfortunately, or I would be happy to help
out with testing.

Thanks,

----Scott.
Patrick Shirkey
2007-12-13 02:57:53 UTC
Permalink
Post by Scott Gifford
[...]
Post by Mark Ellis
I took a look at your changes to synce-serial, good stuff, fiddled a bit
to get them into the current tree, and completely forgot to do anything
else. So I've just committed it. Haven't tried multiple devices because
I only have 1, but I don't see any reason why it shouldn't work, and
it's worth it just from the extra sophistication.
Fantastic, thanks!
Post by Mark Ellis
Anyway, Scott, I'm assuming your question relates only to pre WM5
devices, yes ? In that case, theoretically, odccm should already support
multiple devices. Anyone want to be a guinea pig, try the new serial
scripts, give both vdccm and odccm a go and let us know.
Well, those are the only ones I've used. I don't have access to my
pile of devices anymore, unfortunately, or I would be happy to help
out with testing.
Hi,

I was unable to move forward with the testing and dev for multiple
devices as we moved to using usb-storage on our devices. I still have
the active sync drivers available so I will try to find some time to
test this with a large number of devices in the near future.


Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
Patrick Shirkey
2008-01-21 05:11:14 UTC
Permalink
Hi,

With the latest svn I am able to see two devices at the same time. Nice
work!!!

What is the address scheme for browsing the players?

If I browse to rapip:/ in konqueror I get access to the device on ppp1.

How can I browse to the device on ppp0?






Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
Mark Ellis
2008-01-24 13:35:30 UTC
Permalink
Post by Patrick Shirkey
Hi,
With the latest svn I am able to see two devices at the same time. Nice
work!!!
With serial WM2003 devices I assume, cool, thanks for letting us know.

Are you using vdccm or odccm ?
Post by Patrick Shirkey
What is the address scheme for browsing the players?
If I browse to rapip:/ in konqueror I get access to the device on ppp1.
How can I browse to the device on ppp0?
Off the top of my head (don't use rapip much), and guessing you're using
vdccm, it's either the device name or ip after the rapip part, depending
on how you've got vdccm addressing devices. Without specifying which
device you want, you get ppp1 because vdccm makes the last connected
device the default.

Mark
Patrick Shirkey
2008-01-25 06:37:15 UTC
Permalink
Post by Mark Ellis
Post by Patrick Shirkey
Hi,
With the latest svn I am able to see two devices at the same time. Nice
work!!!
With serial WM2003 devices I assume, cool, thanks for letting us know.
Are you using vdccm or odccm ?
I have windows ce-5.0 running on these device and I'm using usb to
connect.

I tested with vdccm but I can test with odccm too if it is helpful.
Post by Mark Ellis
Post by Patrick Shirkey
What is the address scheme for browsing the players?
If I browse to rapip:/ in konqueror I get access to the device on ppp1.
How can I browse to the device on ppp0?
Off the top of my head (don't use rapip much), and guessing you're using
vdccm, it's either the device name or ip after the rapip part, depending
on how you've got vdccm addressing devices. Without specifying which
device you want, you get ppp1 because vdccm makes the last connected
device the default.
Thanks. Will check it out.


Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
Mark Ellis
2008-01-25 07:15:44 UTC
Permalink
Post by Patrick Shirkey
Post by Mark Ellis
Post by Patrick Shirkey
Hi,
With the latest svn I am able to see two devices at the same time. Nice
work!!!
With serial WM2003 devices I assume, cool, thanks for letting us know.
Are you using vdccm or odccm ?
I have windows ce-5.0 running on these device and I'm using usb to
connect.
I tested with vdccm but I can test with odccm too if it is helpful.
If you wouldn't mind that would be great.
Post by Patrick Shirkey
Post by Mark Ellis
Post by Patrick Shirkey
What is the address scheme for browsing the players?
If I browse to rapip:/ in konqueror I get access to the device on ppp1.
How can I browse to the device on ppp0?
Off the top of my head (don't use rapip much), and guessing you're using
vdccm, it's either the device name or ip after the rapip part, depending
on how you've got vdccm addressing devices. Without specifying which
device you want, you get ppp1 because vdccm makes the last connected
device the default.
Thanks. Will check it out.
Cheers.
Continue reading on narkive:
Loading...