[Synce-devel] vdccm development/dbus

[Mark Ellis]

Hi All

I was just wondering if anyone was currently doing any further work with
vdccm ?

What I actually had in mind was the dbus interface, and I don't want to
duplicate any work being done.

While connection events are passed via dbus in addition to
~/.synce/csock, password requests only go via the socket. It would also
be nice to have an odccm-style get... suite of methods. I'm looking at
this now for use for use with trayicon and gnomevfs, might take a while
since I'm just getting to grips with dbus.....

Mark

[Jonny Lamb]

Post by Mark Ellis
I was just wondering if anyone was currently doing any further work with
vdccm ?

No. This was Volker's dccm implementation, and nowadays he is very busy
and no longer does any work on it. It is advised only to be used in
pre-WM5 devices, and the numbers of people with pre-WM5 these days are
very small.

Ole Andre was implementing WM5 support in vdccm, but found it hard to
get anywhere with the way that vdccm is written, and so he wrote odccm.

Post by Mark Ellis
While connection events are passed via dbus in addition to
~/.synce/csock, password requests only go via the socket. It would also
be nice to have an odccm-style get... suite of methods. I'm looking at
this now for use for use with trayicon and gnomevfs, might take a while
since I'm just getting to grips with dbus.....

To be honest, I would suspect the way forward would be to add pre-WM5
support to odccm. I've never really looked at the dccm implementations,
but I do expect that would a bit of a bigger job than simply adding
these aforementioned methods.

However, as I also mentioned earlier, with the way that vdccm is
written, I expect adding this stuff on might be tricky. vdccm tends not
to use any frameworks, whereas odccm uses frameworks galore. As I said
earlier, I haven't dabbled with the dccm implementations so I'm not sure
how hard it would be to add pre-WM5 support, so I asked oleavr. He said
it wouldn't be hard for someone with a wm2003 device and a basic
understanding of C/GObject.

[Mark Ellis]

Post by Jonny Lamb

Post by Mark Ellis
I was just wondering if anyone was currently doing any further work with
vdccm ?

No. This was Volker's dccm implementation, and nowadays he is very busy
and no longer does any work on it. It is advised only to be used in
pre-WM5 devices, and the numbers of people with pre-WM5 these days are
very small.
Ole Andre was implementing WM5 support in vdccm, but found it hard to
get anywhere with the way that vdccm is written, and so he wrote odccm.

That's pretty much what I thought. I've only been focusing on vdccm
because only have an older device.

What I think may be best then is to provide an option to vdccm to
disable what WM5 support exists, just so it is possible to support
anything on one machine.

Post by Jonny Lamb

Post by Mark Ellis
While connection events are passed via dbus in addition to
~/.synce/csock, password requests only go via the socket. It would also
be nice to have an odccm-style get... suite of methods. I'm looking at
this now for use for use with trayicon and gnomevfs, might take a while
since I'm just getting to grips with dbus.....

To be honest, I would suspect the way forward would be to add pre-WM5
support to odccm. I've never really looked at the dccm implementations,
but I do expect that would a bit of a bigger job than simply adding
these aforementioned methods.
However, as I also mentioned earlier, with the way that vdccm is
written, I expect adding this stuff on might be tricky. vdccm tends not
to use any frameworks, whereas odccm uses frameworks galore. As I said
earlier, I haven't dabbled with the dccm implementations so I'm not sure
how hard it would be to add pre-WM5 support, so I asked oleavr. He said
it wouldn't be hard for someone with a wm2003 device and a basic
understanding of C/GObject.

Cool, for the time being then I'll probably fiddle with vdccm as above
so I can talk to both from trayicon etc, then dig deeper at a later
time. I've only looked at the desktop client side so far, no idea about
the device side.

Hmm, my list is growing.

Mark

[Jonny Lamb]

Post by Mark Ellis
What I think may be best then is to provide an option to vdccm to
disable what WM5 support exists, just so it is possible to support
anything on one machine.

I don't understand this. Just to be clear: vdccm supports pre-WM5 and
WM5. odccm only supports WM5. odccm has a future, and vdccm does not
(IMHO of course).

Post by Mark Ellis
Cool, for the time being then I'll probably fiddle with vdccm as above
so I can talk to both from trayicon etc, then dig deeper at a later
time. I've only looked at the desktop client side so far, no idea about
the device side.

Okay. It's up to you.

[Mark Ellis]

Post by Jonny Lamb

Post by Mark Ellis
What I think may be best then is to provide an option to vdccm to
disable what WM5 support exists, just so it is possible to support
anything on one machine.

I don't understand this. Just to be clear: vdccm supports pre-WM5 and
WM5. odccm only supports WM5. odccm has a future, and vdccm does not
(IMHO of course).

Aha, I'll explain my reasoning. I'm just thinking short term fix here,
as a transition until odccm has pre WM5 support (maybe). odccm is the
preferred option for WM5, but currently for a complete solution vdccm is
needed for pre WM5. vdccm interferes with odccm because it has some WM5
support. Disable WM5 in vdccm to have optimal support for both pre
(vdccm) and WM5 (odccm) on the same machine.

I'm still a bit new to the dccm side, please tell me if i've made a
wrong assumption somewhere.

Ta
Mark

[Jonny Lamb]

Post by Mark Ellis
Aha, I'll explain my reasoning. I'm just thinking short term fix here,
as a transition until odccm has pre WM5 support (maybe). odccm is the
preferred option for WM5, but currently for a complete solution vdccm is
needed for pre WM5. vdccm interferes with odccm because it has some WM5
support. Disable WM5 in vdccm to have optimal support for both pre
(vdccm) and WM5 (odccm) on the same machine.

Yes that's okay, but although odccm is "preferred", if I had both a
WM2003 device and a WM5 device, I would simply use vdccm. I wouldn't use
two daemons for essentially the same thing.

I also think that disabling simply WM5 support in vdccm will be harder
than it sounds..

[Mark Ellis]

Post by Jonny Lamb

Post by Mark Ellis
Aha, I'll explain my reasoning. I'm just thinking short term fix here,
as a transition until odccm has pre WM5 support (maybe). odccm is the
preferred option for WM5, but currently for a complete solution vdccm is
needed for pre WM5. vdccm interferes with odccm because it has some WM5
support. Disable WM5 in vdccm to have optimal support for both pre
(vdccm) and WM5 (odccm) on the same machine.

Yes that's okay, but although odccm is "preferred", if I had both a
WM2003 device and a WM5 device, I would simply use vdccm. I wouldn't use
two daemons for essentially the same thing.

Ok, that's fair enough, I wasn't sure how good the WM5 support was in
vdccm.

Post by Jonny Lamb
I also think that disabling simply WM5 support in vdccm will be harder
than it sounds..

Having had a look at it I think you're probably right on that one.