Hi All Let me explain where I think I'm coming from with this first. Sorry if I ramble.
Ignore hal-dccm for now, because hal uses dbus it'll be close enough to odccm to make migration efforts easy. And it's next on my list.... We still have multiple dccms obviously. I'm not going to comment on the functionality differences between v and o because, as far as I can tell, they do exactly the same thing. They do it in different ways, but it amounts to the same. The only significant difference is client communication, clients being pls, raki, trayicon etc. Of these the only ones that are affected by the differences are raki, trayicon, anything that actually gets notified of devices connecting etc, everything else is oblivious to this because they go through rapi. I'm sure most of you know this. odccm uses dbus, vdccm uses a control socket in ~/.synce called csock. Personally I think dbus is the way to go (and later hal). The crunch is then that raki in synce-kde doesn't work. I did try and jam dbus into raki, but I don't know much C++, I'm not a kde/qt developer, synce-kde uses the previous release of qt (I think) and, while dbus support for that version exists, it appears to be completely undocumented. Sigh. Plan 2, a fake vdccm that translates from odccm to raki (or anything else dependent on vdccm style) and vice-versa. I've checked it into trunk as o-vdccm, it'll build a single binary called vdccm. Seems to work ok, even passwords work. Comments and suggestions ? Mostly is this the right way to go, at least for the time being ? Mark ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
