[Telepathy] Telepathy 1.0 will never happen

[Robert McQueen]

On Tue, 2011-05-31 at 08:46 +0200, Guillaume Desmottes wrote:
> >   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.
> 
> I'm not so sure about that. Having a bit TP module kinda scares me but
> I'm ready to be convinced otherwise.

It'll be fine. :D We need to put the things into the same module which
are already implicitly tightly-coupled - this just makes it explicit and
allows us to change eg MC's implementation at the same time as the D-Bus
API and client APIs. We'll do time-based releases and the transparency
and predictability will go up a great deal, which is beneficial for
everyone.

> > Concretely, telepathy-glib would be split into three shared libraries:
...
> Where would live common types such as, say, TpHandle? Both
> telepathy-glib-dbus-N and tp-glib will use it and tp-glib will have to
> expose it in its public API.

It's in the same boat as TpProxy in that case. Does it have code
associated with it which is needed from both a low and a high-level
situation, or could we have a typedef in one library and code in the
other, or just two types?

> > Empathy and other applications would (ideally) just use telepathy-glib;
> > CMs would use telepathy-glib and telepathy-glib-dbus-N. 
> 
> Some clients (such as gnome-shell) already use only high level API (as
> that's the only API binded with gir). I'm doing a lot of work to move
> Empathy from low level API to high level ones (cf my recent work on
> TpChannel and friends); I'm planning to continue doing so.

++ TpQt4 is already far further ahead in this aspect.

> > 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?
> 
> tp-python is already unmaintained. I'd be in favour of continuing making
> new releases containing code gen for new major spec but only for CM.
> Maybe we could even drop its client code to clearly assert that tp-glib
> + gir is the way to go, especially now with all these awesome new high
> level API.

I think it's clear that in the longer-term the client side story for
Python has to just be tp-glib high-level APIs with PyGI bindings. At the
moment the client side story is so weak anyway I don't think deleting it
is a hardship.

The service side is the problem - until we have GDBus port of the
low-level / service side of tp-glib, then it will become fairly hard /
impossible to keep up with the D-Bus API particularly if we go on a big
deprecated-API-delete-a-thon (which I am certainly going to join in with
- I wrote half of the old/bonged APIs so I'm looking forward to deleting
them :D).

As an interim, to allow Python CMs to even be possible to exist any
more, maybe we need to also include generating the service side of the
D-Bus API in the main Telepathy module, with appropriate constants so
you can keep up with interface renaming. Quite how to detect API breaks
(there will be no build failures) is hard though.

> 	G.

Regards,
Rob

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