On Feb 16, 2012, at 03:16 PM, Scott Kitterman wrote: >On Thursday, February 16, 2012 12:07:58 PM Steve Langasek wrote: >> On Thu, Feb 16, 2012 at 12:04:03PM -0800, Steve Langasek wrote: >> > Bear in mind that dbus is not running on servers by default. So that >> > would be a fine solution for the desktop, but there's a larger >> > architectural decision to confront there if we think that should be the >> > solution on servers as well. >> >> Evan Broder has set me straight here that we *are* installing dbus by >> default, and I see that it's part of the 'standard' task in precise. So >> nevermind. :) > >Right, but that doesn't make it a good thing. > >DBus is a desktop technology and I don't think there's a compelling use case >for adding this additional complexity to servers. > >Myself, I'd prefer it go away. I'm not clear why it was added.
I don't have a particularly strong opinion about whether dbus should or should not be installed on servers, but given that c-j was originally intended (and maybe still is <wink>) as a desktop application, I think it makes sense that it's implemented as a dbus client/server. It certainly improved some usability problems in the past. Having said that, the dbus service is a fairly thin wrapper around the backend library, although that latter isn't really well suited to be used as a library atm. I think it could be with a bit of work though. The real question as to the future of c-j is whether it's even the right approach to cleaning up your system. If so, then maybe a bit of engineering to clean it up, better separate the backend from the dbus, ui, and cli interfaces, and package it in a better way would be worth it. Cheers, -Barry -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
