[Telepathy] Telepathy 1.0 will never happen

[Guillaume Desmottes]

Le lundi 30 mai 2011 à 18:17 +0100, Will Thompson a écrit :
>   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.

Sounds like a very sane idea.


> 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.

I'm not so sure about that. Having a bit TP module kinda scares me but
I'm ready to be convinced otherwise.


> 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.

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.

> 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.


> 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.


	G.