[Telepathy] RFC: drop libtelepathy-glib-unstable

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Aug 7 07:24:28 PDT 2007


Currently, telepathy-glib builds auto-generated service-side interfaces
into two libraries:

* libtelepathy-glib (shared with SONAME libtelepathy-glib.so.0, also static)
  The interfaces from the spec for which we believe the API/ABI will not
  have frequent incompatible changes
  (hereafter referred to as tp-glib)

* libtelepathy-glib-unstable (static only)
  The rest of the interfaces from the spec
  (hereafter referred to as tp-glib-unstable)

Gabble HEAD only uses tp-glib. It also ships a copy of the same auto-generation
machinery, which it uses to build interfaces for spec extensions
(currently the OLPC-specific interfaces).

The Tubes branch additionally uses tp-glib-unstable for Tubes.

Salut HEAD uses both tp-glib and tp-glib-unstable (for Tubes). It also ships a
copy of the same auto-generation machinery, to build extensions - it has the
same OLPC-specific interfaces as Gabble, plus Channel.Type.FileTransfer which
is targeted for eventual spec inclusion.

Idle uses tp-glib-unstable (for Renaming, which tbh could probably land
in the shared library fairly soon).

Now, the Tubes API is about to change in an incompatible way. This will
cause build failures if old versions of (Gabble|Salut) are built against
new versions of tp-glib-unstable or vice versa.

Possible solutions:

* Give CMs a copy of the tubes spec (or other unstable modules) that they
  implement, in their extensions/ dir.

  + This changes the namespacing (e.g. tp_svc_foo -> gabble_svc_foo) and
    makes them independent of tp-glib-unstable, so unstable
    specifications can evolve at their own rate
  - CMs need their own copy of the auto-generation stuff (but in
    practice, Gabble and Salut have one anyway, so this only affects Idle)
  - Widespread, but easy and automatable, changes in CMs (because of the
    namespacing change)

* Keep using tp-glib-unstable. Require users and developers to keep
  tp-glib-unstable in sync with whatever CMs they're building.

  + CMs only need auto-gen machinery if they actually build spec
    extensions (currently this only affects Idle, though)
  - tp-glib-unstable keeps changing its API/ABI
  - static linking required
  - distribution maintainers will hate us (as soon as we get a cryptic
    build failure in their distro because they weren't in sync - worst
    case, a security update of Gabble)

I think we should port Gabble and Salut to use their extensions
directory for the tubes code, add an extensions directory to Idle (or
possibly just move Renaming to the tp-glib shared library), then get rid
of tp-glib-unstable in some future telepathy-glib release.

Questions, comments, approval, objections?

	Simon


More information about the Telepathy mailing list