glib in kdesupport: yes or no?
Aaron J. Seigo
aseigo at olympusproject.org
Tue Mar 11 02:11:04 GMT 2003
-----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-----
More information about the kde-core-devel
mailing list