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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
