glib in kdesupport: yes or no?

[Aaron J. Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 09 March 2003 10:50, Havoc Pennington wrote:
> I've been relying on the KDE developers involved to tell KDE about
> D-BUS, rather than doing it myself; I have my hands full selling it to
> GNOME as some may have noticed if you lurk on our flamewars. ;-) But
> I'd be happy to do a 'briefing' for this list.

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.

as someone else noted, you keep making a GNOME/KDE distinction in the context 
of a project that you are trying to be agnostic to such issues. unless the 
expectation is to have one subset of projects adopt it and make it a forced 
defacto standard, which should be the last option entertained rather than the 
first.

personally, i'd love to see a commonly accepted IPC mechanism. it would allow 
us to pool our bug reporting and fixing efforts, it would allow apps from all 
over the Free Software world to communicate with each other, etc...

HOWEVER, because that is a noble and good goal we need to be careful to do it 
right. this means being as open as possible and drawing in as many people as 
possible from day one. it means looking at the successes and instead of 
throwing them away looking at how to learn from or improve those existing 
technologies. and then communicating back the reasons for those decisions.

i'm glad that this thread exists if ONLY because it is going to force that 
process to begin, IMO. when i first heard about dbus i went looking for 
information on it and while i liked the concept i could find out so little 
about it's implementation and design that i couldn't help but be wary and 
concerned about it.

and that's from someone who thinks a common IPC mechanism is a good idea. not 
everyone is even that far along.

if we want to help various projects (thinking beyond even KDE and GNOME) adopt 
common technologies, we're going to have to communicate with everyone in an 
open manner. if we want to continue writing what we want to write how we want 
to write it in our own little spaces, then we will have an automatic limiter 
to how far interop can be taken. even within that limited space we've come a 
long, long ways, so it isn't necessarily automatically bad in ever case.

but if interop is the goal, independence is a necessary trade off to achieve 
success, and one that we aren't making right now. =/

when every distribution of linux puts its own face on KDE and GNOME and calls 
it a bid for interoperability, i say they aren't seeing the larger picture 
that they are all linux and are therefore just relocating the interop problem 
to a place where it is much harder to fix. when i see two programmers quietly 
reinventing something that is for interop purposes but who keep framing their 
intentions in platform-speak, i see that as entrenching the interop problem.

hrm. is this thread off-topic?

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

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+bOrO1rcusafx20MRAma9AJsFrFozNZoU2hv2cQzTHVskhOglggCfVZCN
XpvSquu/7wIB04l7wrOgwSQ=
=YrFy
-----END PGP SIGNATURE-----