glib in kdesupport: yes or no?

[Maks Orlovich]

> Keep in mind a couple of things, 1) D-BUS is maybe 30% done if that
> and still open to large changes 2) there were more KDE developers
> initially involved than GNOME developers, quite a few people (a
> dozen-ish I think?). 

Note that no group of KDE developers smaller than kde-core-devel is IMHO 
adequate to make any sort of core decisions. Sure, it's the maintainers call, 
but it affects other areas as well. I do, for instance, promise to fight for 
every millisecond of startup time.

> I'd encourage everyone to get involved and to look at the
> design/implementation. The list archives contain all discussion that's
> occurred and have always been public. Also please feel welcome on

This is rather academic, since it has never been publically announced. That's 
like saying something written in the bark of a tree 5 miles inside a forest 
is public, in a way -- it's only public if you're already know about it, 
anyway. Or, to be more concrete, it's like saying that you should know that 
your planet is about to be destroyed since the plans were available, afte 
rall, just a few light-years away. 

> An important question for KDE is, *if* you were going to use it in
> addition to or instead of or as a backend for DCOP, how would that
> migration work, and how would the code be set up.  e.g. would you a)

My question is how any of these would affect our stated commitment to keep a 
stable API through ages. 

You're, of course, also fully ignoring the issue of wire compatibility, which, 
AFAIK, KDE has kept since 2.0.

I also have a simple question to ask to any person who wants to propose 
breaking any API in a hypothetical KDE4: "Are you willing to port all the 3rd 
party apps". 

The easiest path, of course, is to just use DCOP. And please don't tell me "it 
requires Qt". If you can't re-implement QDataStream's marshalling, I dare say 
you shouldn't be coding.