From kde-core-devel Tue Mar 11 02:11:04 2003 From: "Aaron J. Seigo" Date: Tue, 11 Mar 2003 02:11:04 +0000 To: kde-core-devel Subject: Re: glib in kdesupport: yes or no? X-MARC-Message: https://marc.info/?l=kde-core-devel&m=104734872815867 -----BEGIN PGP SIGNED MESSAGE----- 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 http://www.freedesktop.org/software/dbus/ ? 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. blah. 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 course. 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' http://www.kde.org http://promo.kde.org/3.1/feature_guide.php -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+bUW41rcusafx20MRAlI7AKCman3IcA8C1teLwjLGvtGrOQxWZwCgmSTi XD5lSXXdK49T3B0nAGN7Xe8= =NFe4 -----END PGP SIGNATURE-----