[Telepathy] Telepathy 1.0 will never happen

[Robert McQueen]

Replies on a few points...

On Tue, 2011-05-31 at 10:01 +0200, Xavier Claessens wrote:
> I'm a bit scared about merging in the same repository, especially
> tp-glib and tp-qt4. They do not have the same person hacking on them,
> not the same priorities and schedule. For example tp-qt4 would currently
> be driven by meego (and KDE?) releases, while tp-glib by GNOME releases.

This is the point of also introducing time-based releases at the same
time, so that whoever is bringing a feature into Telepathy (for Qt4,
Glib, or both) can just do it in one branch, crossing
backend/spec/binding, and know when it can be expected to appear in the
next Telepathy release. This allows a lot more certainty than the
current situation, where you have to chase/beg/etc separate module
maintainers for review and release, which is very time-consuming and
unpredictable.

> >   3. Include version numbers in D-Bus interface names.
> 
> Would that version be a requestable property, so Empathy could request a
> channel implementing Message iface version 0.5 and if CM only implements
> 0.4 then the channel request fails and empathy could tell "sorry please
> upgrade your CM"? Or am I missing the point?

No, it would be, im.telepathy.v12.* on D-Bus would change to
im.telepathy.v13.* because some methods have gone away. This means for a
running component, chunks of Telepathy functionality (eg all of the CMs
and all of the handlers) simply disappear when you upgrade
tp-glib/tp-qt4 on your system. Note there is something important we have
to do here: make a mechanism for clients and CMs to autogenerate
their .client / .manager files correctly.

Upgrades therefore require a Telepathy shutdown/restart. In practice,
this works so badly at the moment (MC doesn't detect new handlers, etc)
that I don't see this as a real regression. To improve the UX we would
simply have something which detects this situation and provides a
reconnect button, in the same way that Firefox or Linux kernel updates
are handled on modern distros.

> But what if the CM does
> not support the new "Foo" with extra args? I guess the high-level
> binding would require a specific version of the interface, and if the CM
> implements an older version, we pretend the interface is not implemented
> at all, so the feature would not be supported? The other solution is to
> include all CMs into that big repository as well... not sure it's a good
> idea...

What happens is, that CM just stops compiling with this version of
Telepathy until someone fixes it. The reality / expectation is that you
have to remain closer to the Telepathy project to maintain a connection
manager effectively. In practice if we introduce a new API feature in
order to support a UI (FooDetailed) we have to go and fix all of the CMs
we care about. This just turns the "subtle regression and bitrot"
situation we have now into "very blatant build failure - buildbot goes
red and someone must fix".

> > 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.
> 
> Why tp-logger? The logger is a client as any other user of tp-glib
> high-level API, no? Empathy communicate with the logger via a C api, not
> dbus interface AFAIK, no? For MC it is the same as with CM, if we
> include MC we should include all CM as well, no?

No, I think in reality we never expect to have any other MC
implementations, whereas we expect (design) to have many CMs. It took us
long enough to arrive at one working MC implementation and I can't see
any reason/incentive to write another any time soon. Certain features
require crossing between MC, spec and client libraries already - eg the
"just send one message" API which was added to TpQt4 recently.

The logger is a little more debatable but there are already glib and Qt4
APIs for the logger functionality - I think the delicate
handler/observer dance is already subtle enough that as a project we
should aim to deliver a higher-level conversation API that just takes
care of history, using the logger, rather than forcing client developers
into understanding this strange corner of the spec and message IDs and
stuff.

> > 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.
> 
> I also think we need more predictable stable/dev cycles and make all tp
> components sync on that.

Right, we'd have merge windows / stabilisation windows to go along with
the time-based releases.

> >   • telepathy-glib-dbus-N (for integer N), the generated code for major
> > version N of the D-Bus API.
> 
> Do we want to expose that lib? I think it should be only internal into
> tp-glib high-level. Or do you think we should still let Empathy use that
> lib directly to experiment even if we do not give any ABI stability
> guarantees?

The CMs would likely use this low-level library - I'm not sure I agree
it would change name per D-Bus interface version - I think it just
breaks ABI in lockstep with the D-Bus API.

> 1) I think it is important to get generated spec documentation online
> more quickly, maybe setup a hook in git repository that rebuilds and
> publish online at each commit? Would have a page spec-stable and
> spec-dev?

I don't think it's that important because I think nobody other than us
uses the spec any more, partly because it has so much deprecated stuff
in that it's now incomprehensible if you're not a Telepathy developer.
We should focus on what our end-users need, well-documented and
understandable client library APIs.

> Regards,
> Xavier Claessens.

Regards,
Rob

-- 
Robert McQueen                                 +44 7876 562 564
Director, Collabora Ltd.             http://www.collabora.co.uk