Re: KDE Interop [Was: D-BUS background]

["Chris Chabot" <chabotc xs4all nl>]

From: "Zack Rusin" <zackrat speakeasy net>
> Standardized message bus would not only profit desktop environments as
> almost everyone here seems to think. This goes beyond KDE and GNOME.
> System wide daemon sending messages whenever a new device is connected,
> screensaver app sending messages whenever a screensaver is about to
> start... There's so many places one could use that thing.
..
> Now lets say we agree that our
> address book interface will containt a message like
> "org.freedesktop.AddressBook.NewContact" that takes the vcard as a
> string as the argument. You send that message and whatever addressbook
> you use it will take over (and KAddressBook is really good ;) ). No
> code duplication in the email client and we have an interdesktop
> addressbook sharing. As you can imagine the permutations of the above
> template are infinite.

Exactly why i am excited about this idea.. Simple examples are easy to think
of, such as setting 'Default desktop font' or which screen saver to use and
having it apply on all desktop envirioments. Take it one step further, and
you wouldn't just store & retrieve vcards but you could do the same for your
music, movie & image collections. Whats more, it would be
backend-independent. Which in turn allows more choice (using kaddressbook
for storing & retrieving vcards in evolution anyone?)

The usage of these services would become a lot easier to; One api to learn,
which applies to recent documents, addresses, etc. No need to think about
ldap or database or other api's for storing & retrieving addresses (-etc),
thus faster development, less bugs and more consitent results.

Choice and seperation would also mean being able to make better, specialised
backends. Address book management, recent documents, music, movie and image
collections .. For each well defined service you (and/or your distro
builder) could choose the backend you that works best, without having to
apply a single patch or changing a single setting. And thats without
thinking about easier maintanance, enterprise/large rollout implimentation,
etc. Sharing efforts between different distro builders and desktop
envirioment teams would become a lot easier allowing linux as a desktop to
grow faster then it would otherwise.

It could even be used to solve one of the other topical problems: How do you
impliment system configuration within gnome? If a backend does the distro /
platform specific configuration, the gnome/kde/whatever dialogs only need to
talk to that, without requiring knowledge of the platform they are running
on. Hell, you could even do remote machine configuration & cluster
management (if you go that far, security needs to be quite good obviously).
Using that combined with things like lm-sensors and other hard&software
monitoring & configuration tools you could build quite complex enterprise
level tools for maintaining large networks and/or server farms.

Ofcource it will be a while before we could even dream about reaching that
level, but the posibilities i imagine / hope for go far beyond simple
'insert cd notification'. It could be a tool, if done right, to solve quite
a few issues that are present in linux today and help prevent some of the
duplication of effort that is happening now between distro and desktop
camps.

I'm actualy quite looking forward to what direction redhat forinstance will
go with this, it might simplify some of the work related projects i need to
do quite a bit, maybe i'll be able to contribute a backend or two (main
things that would be relevant for me would be security and still having
decent communication speed despite the extra hop for the messaging)

Anyways, enough ranting for one email ;)

    -- Chris