[Telepathy] Telepathy 1.0 will never happen

[Will Thompson]

Hi,

[Alarmist, controversial subject line intended to encourage people to
read a long email! :) Most of this email is fundamentally the idea of
the notorious Robert A. McQueen, with input from bouncing off various
other Cambridge-based folks.]

Back in December, I muttered in Dublin about a rough schedule for
Telepathy 1.0, including deleting a tonne of deprecated D-Bus API,
porting telepathy-glib to GDBus, and a few other things. As we can see,
this has not happened. This kind of massive flag day is infeasible: it
would take a *lot* of concerted, thankless effort to get all the stars
aligned at exactly the same time. So it's safe to assume that it will
never happen without some rethinking. How can we get from here to a
future where we delete all the legacy baggage without having to rewrite
everything simultaneously?

One major factor which makes hacking on Telepathy frustrating is that
we're not merely bound to a GLib API and a (basically independent) Qt
API: there's also the D-Bus API, which leaks up into the GLib and Qt
APIs too. So it would be an improvement if we could relegate the
specifics of the D-Bus API to being an implementation detail which we
can modify independently of the API that application developers use.

This would introduce stronger dependencies between versions of different
components, but these dependencies already exist: when the
MailNotification specification changed between the first and second
drafts, upgrading Empathy without upgrading a CM broke mail notifications.

So here are some proposals:

  1. Split telepathy-glib and telepathy-qt4 up to separate the
hand-written API from the D-Bus API, allowing applications to use the
former without depending on a specific version of the latter.

  2. Merge them into the same repository as the spec, removing several
steps from the “write spec; get spec merged to spec repo; get spec
released; copy-paste spec to tp-glib; write high-level C API; release
tp-glib; copy-paste spec to tp-qt4; write high-level Qt4 API; release
tp-qt4” hurdles between here and cake island for any new feature.

  3. Include version numbers in D-Bus interface names.

  4. Never have to worry (much) about D-Bus API stability again, at
least for peripheral interfaces.

This would make developing new features (like, say, OTR! topical)
easier: spec drafts could be merged and generated code included in
releases without having to commit to that D-Bus API forever. Currently
we copy-paste spec drafts into between 2 and 4 components, and then when
the glorious day comes when the draft becomes stable, every one of those
components needs to be sedded *even if nothing has changed*. Avoiding
this feels like an improvement to me.

Similarly, telepathy-glib and telepathy-qt4 both contain API that
depends on recent, specific versions of Mission Control, and yet do not
formally depend on those versions of MC. And telepathy-logger bindings
are out of tree for both due to API stability concerns. So potentially
more controversially:

  5. Merge Mission-Control and Telepathy-Logger into the One Big
Telepathy Module.

Then we would tag, Chromium-style, a Telepathy major release every six
weeks (say), which would contain the Glib binding, the Qt4 binding,
Mission Control and the logger, all known to implement compatible D-Bus
APIs. This would get rid of the tendency to delay releases to sneak one
last feature in (as we had for the stable branches recently): missing
the window wouldn't be critical, because it rolls around regularly and
frequently.

Concretely, telepathy-glib would be split into three shared libraries:

  • telepathy-glib-proxy, which basically just contains TpProxy (and
would go away in a future where something equivalent is in GLib and
tp-glib moves to it).

  • telepathy-glib-dbus-N (for integer N), the generated code for major
version N of the D-Bus API.

  • telepathy-glib, which depends publicly on telepathy-glib-proxy and
internally also uses telepathy-glib-dbus-N.

Empathy and other applications would (ideally) just use telepathy-glib;
CMs would use telepathy-glib and telepathy-glib-dbus-N. Telepathy-Qt4
would undergo roughly the same transformation. It's already part-way
there: applications have to #define a magic flag to enable access to the
generated D-Bus bindings.

The C CMs will have to depend on the D-Bus API versions, so breaking
D-Bus APIs will involve running around changing all the CMs. But in
practice this is what we have to do anyway whenever we add anything to
existing interfaces; except where we have base classes and mixins to
avoid duplicate, in which case a recompile should be enough in the new
world order.

Outstanding issues: what happens to telepathy-python? Does it move into
the big Telepathy bundle along with the other libraries, and ultimately
get replaced by gobject-introspected telepathy-glib?

This explicitly does not include a GDBus port/rewrite of telepathy-glib.
It would make one easier to do later, but it shouldn't be a prerequisite
for making it easier to hack on Telepathy in general.

Thoughts?
-- 
Will