GNOME 3.0 release delayed

Largely. Many modules have already been "ported" (removed use of deprecated functions) but a little more work will be needed after Benjamin Otte's rendering clean up branch lands (especially in GNOME Games).

> * Will it include Zeitgeist, which was deemed not ready for a Fall 2010 release?

If they resubmit their module application and address the issues that got them rejected last time, then yes.

I remember when they choose to make a CORBA-base system, there were a lot of complaints that CORBA systems would always be unnecessarily slow. IIRC, one of the reasons the Orbit (CORBA) proposal won was that OpenOffice.org was using CORBA ("Uno"), and it would make integration easier, but I don't remember this really happening.

however, gnome 3 will mostly use the new gdbus implementation in glib, which may well be faster than libdbus. however, it's still unlikely to be faster than orbit. orbit was fast, but didn't have the right features.

all this said, afaik libdbus has never been seriously optimized (or at all optimized) since this effort in 2004:
http://lists.freedesktop.org/pipermail/dbus/2004-November...
and that 2004 effort was largely ruined when arbitrary recursive types were added to libdbus later on, which rewrote a bunch of the code.
See also http://log.ometer.com/2006-07.html#21

gdbus may still need profiling and tuning, or someone may have already done it, I have no idea.

I think the reason libdbus hasn't been seriously optimized is that it rarely shows up in profiles unless someone is doing something idiotic. It's common on Slashdot or whatever to assume that X is slow due to IPC, or GNOME is slow due to CORBA, or whatever, but the reality is that I've never seen IPC near the top of a profile for a desktop app, unless the app was doing something fundamentally bad that experienced desktop programmers know to avoid these days.

The rules are pretty simple for both X and dbus, for example:
* don't make blocking round trips where you wait for IPC to complete and lock up the whole app
* design the out-of-process interface to avoid round trips and to avoid "too much" IPC
* use shared memory if you're going to shovel some giant block of data (though unix domain sockets are so fast, this is less important than one might think)

If you plan things so you have dozens or a hundred IPC calls instead of thousands, and don't have to block for call 1's result in order to make call 2, you'll be fine. One advantage of dbus is that it has a lot of features designed to *avoid* the need to block in a round trip, and the new gdbus API has some nice features to help apps avoid this.

I think server-side programmers often have the wrong intuition here, because of course IPC is going to be a bottleneck for server apps that are mostly about handling network requests. But desktop apps mostly spend their time drawing pixels or waiting for mouse events or waiting on the filesystem or any number of things, while their use of IPC is just a few messages here and there. Also, desktop IPC is unix domain sockets, which are just elaborate cross-process memory copies. This is pretty different from TCP.

A historical issue was the idea of using IPC for a "component system" so that an app could be made up of a swarm of different processes; that architecture would indeed tend to bottleneck on IPC. However, it was a bad idea and a lot of the design of dbus was done with this use-case specifically excluded. The modern GNOME equivalent of "component system" in this sense would be GObject plus gobject-introspection, an in-process setup.

I'm sure profiling (and optimizing based on said profile) libdbus and gdbus would be a fun project, and welcome. But I don't know if there's anything that would be user-visibly faster in GNOME afterward.

Do you have anything constructive to say, at all?

So your implication that the Gnome/MacOS convention is somehow objectively the wrong, and less accessible, one is just not true (or, at least, unsubstantiated). For Gnome to switch to the other convention now would be the real accessibility fail, since that would break with the convention that their users are used to.

If that's your primary evidence that it's "broken by design", they would seem to be doing pretty well...

Alex