[Telepathy] Telepathy 1.0 will never happen

[Xavier Claessens]

Le lundi 30 mai 2011 à 18:17 +0100, Will Thompson a écrit :
> Hi,

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

I totally agree with this! tp_cli_ API should never as been made part of
tp-glib's API/ABI. We had to do so because historically we didn't have
all the high-level APIs, but this should be stopped now.

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

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.

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

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

+100! Spec generated code should not leak anymore in high-level API/ABI,
so breaking the spec should be just fine for all apps, if the high-level
binding can deal with it to hide the difference. For example currently
we are changing a signal "Foo" with "FooDetailed" because we realized
that it miss some info. I think we could just break the spec to add args
to "Foo" and the high-level binding would be updated before releasing
with that new spec, and apps would never know. 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...

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

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

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

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?

>   • 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?

I think its client-side API could already be dropped in favor of g-i of
tp-glib. Its service-side API should be discouraged to use and we can
keep it like now mostly unmaintained, and work on g-i for service-side
of tp-glib.

I think moving to gdbus would help a lot to get good g-i for
service-side, they added all the needed base classes and codegen in glib
2.29.x with a proper "mixin" system.

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

I think porting to gdbus should be a goal once glib 2.30.0 is released
because they recently added everything we need. But I totally agree
that's only one step to a better telepathy world, and we can already do
the other steps :)



I would like to add some thoughs:

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?

2) Would be great to "upstream" our spec format. GLib now has a codegen
python script, would be awesome if we can work with them to extend their
xml format with all our documentation tags and make their script
generate html doc as well. It would benefit everyone.

Regards,
Xavier Claessens.