glib in kdesupport: yes or no?

Aaron J. Seigo aseigo at
Tue Mar 11 02:11:04 GMT 2003

Hash: SHA1

On Monday 10 March 2003 12:54, Havoc Pennington wrote:

(More interesting, IMHO:)
> Even on the libICE-equivalent layer, we still have a major issue up in
> the air, which is the kind of type system it uses:

this is one of those issues will likely make or break dbus. which, given that 
one hopes such a protocol would be in production use for at least 5-10 years 
after it is stabilized (e.g. bug free ;), that's no small decision.

personally, i'd love to see both recursive and collection types, with perhaps 
the latter being "embedded dbus objects" that can thereby map down eventually 
to primitives (even if one of those primitive ends up being raw binary data). 
in a previous life where i had^H^H^Hgot to work on a light weight IPC system 
similar to this we had great success with embedding messages inside of 
messages since then one simply bootstraps the send/recv processes to get 
complex types.

i appreciate the work being done on this by all involved, assuming that the 
intentions and end results are good. and i think that end results follows 
directly from one's intentions.

(Still interesting, but probably to fewer people, IMHO:)
> On Mon, Mar 10, 2003 at 12:43:10PM -0700, Aaron J. Seigo wrote:
> > perhaps a briefing that isn't aimed at any specific project would be in
> > order. a quick web page describing what it is and how it works  and what
> > the current design is on the technical level posted somewhere would go a
> > long way. that would head off 99% of issues that will surround dbus one
> > day right now.
> Have you seen the docs on ?

yes.. i actually spent an evening reading those docs last week. i've also read 
every message as of that day in the email archives... i think where it fails 
to help is in understanding how it relates to current practice.

it really feels like, while reading those documents, that one is simply 
looking around and saying, "Light weight IPC is a Good Idea(tm), therefore we 
need to introduce it to GNOME and trump the existing system there and ignore 
extending KDE's already existent and robust IPC mechanism for political 
reasons. maybe we can leverage this into Apache and other projects by making 
it an inescapable de facto standard." that's reading between the lines, i 
know, but that's how it comes off. 

i hate de facto standards. anyone attempting to accomplish a "standard" by 
convincing the world it's "de facto" is not playing by the rules of pragmatic 
appreciation of quality but by the rules of dictatorship.


i assume (but feel free to prove me wrong ;) that you are actually thinking 
something more like, "Light weight IPC is a Good Idea(tm), let's make 
something like, but better than, DCOP (and here's why we can't simply extend 
DCOP) that everyone can use if they see the need for such capabilities on 
Linux. Let's make it so good (both technically and license-wise) that 
everyone will choose it for their light-weight IPC needs for the following 
reasons: blah blah blah." if this is close(r) to your thoughts (which, 
guessing by reading the COPYING file it is), then that needs to be 
communicated clearly. IIF you want easy buy-in from other projects, of 

yes, this is "politics" in that it realizes that there are better and worse 
ways to represent something to those you look to for buy-in. but people are 
people and they prefer to feel like you are running with them rather than 
running around them.

so far, i'd like to suggest that the way DBus has hit the scene has NOT been 
useful nor good. i've already had numerous user requests to me personally 
(why do they do that?!?!?!) to explain DBus + KDE and what it all means. i've 
also been involved in some developer <-> developer discussions that went the 
same way. there is already unecessary damage control to be done.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE: The 'K' is for 'kick ass'
Version: GnuPG v1.2.1 (GNU/Linux)


More information about the kde-core-devel mailing list