roadmap

[Havoc Pennington]

Hi,

On Wed, Aug 6, 2008 at 4:36 PM, Colin Walters <walters at verbum.org> wrote:
> That's about it, after that I think we can call it done.

Yay! (let's hope it sticks)

> The bindings of course are a whole other thing; sort of far background
> on my tasklist is to look at telepathy-glib and see whether it makes
> sense to promote it to "dbus-glib2" effectively.

The one thing I really hope to see in this is support for async
versions of connect/disconnect, acquire/release name, watch/unwatch
name, watch/unwatch signal ... in all cases treating the first time
the same as subsequent async changes, i.e. you get a callback in an
idle the first time and all your logic is simply in the callback,
there's no "first time"/inline case done differently. This way the
async / changes-later case is tested and there's only one codepath.

For example, when you acquire a name, you should specify a "name
acquired handler" which is called once when you first acquire it, and
subsequently if you acquire it again, and also specify a "name lost
handler" to handle being replaced. Compare to dbus-bus.h convenience
API which is mostly synchronous and blocking and does not deal with
later events like losing the name.

Doing connect/disconnect this way is the only way restarting the
system bus would ever have a hope of working, though in practice I'm
not sure it's worth it, it does have the virtue that it could mildly
boost app startup time to do connection asynchronously.

(like hippo-dbus-helper, but cleaned up a lot, e.g. should use
GClosure, honor invalidating the closure to disconnect, and have
disconnect IDs not just disconnect by func to support bindings)

(I haven't looked at telepathy-glib yet)

Havoc