telepathy/ Roadmap

Status of planned changes and additions to the Telepathy API.

6.0

The full initial proposal is here: http://lists.freedesktop.org/archives/telepathy/2011-May/005525.html

Summary: Actually, I'm not going to try summarising. Please read the proposal above before continuing.

telepathy-core version number is higher than the version number of everything in it, and MC is currently on version 5.x.

Steps to get there:

  • 5.91 -- release everything as one module as-is.
    • i broadly think that being able to release the components as they currently stand all at once is a good step 1
    • Drive tp-qt4's CMake-based build system from autotools.
    • Use git-subtree and lots of git-merge to keep everything up to date.
    • Directory structure would look like (courtesy of smcv, but not including the CMs): 
    ${top_srcdir}
    \- configure.ac (top level)
    \- doc/
       \- glib/
       \- qt4/
    \- examples/
       \- glib/
       \- qt4/
    \- mission-control/
    \- mission-control-plugins/
    \- m4/
    \- spec/
       \- Account.xml (etc.)
    \- telepathy-farstream/
    \- telepathy-glib/
    \- TelepathyQt4/
       \- Farstream/
    \- tests/
       \- lib
       \- glib
       \- qt4
       \- mc
          \- account-manager
          \- dispatcher
    \- tools/
  • 5.93 -- deprecate fragile API/ABI
    • Kill off telepathy-glib/svc-* and move them to telepathy-glib-dbus-vX (? see Open Questions below)
      • The equivalent change in tp-qt4
        • I'm not sure proxy.h goes to tp-glib-dbus-vX, because that API needs to be exposed by tp-glib high-level. that would mean tp-glib-dbus ABI breakage would break tp-glib too, no? -- Xavier Claessens
        • Good point (my memory of what is generated and what isn't is unreliable) Fixed. -- alsuren
      • Kill telepathy-glib/tp-cli-* too -- Xavier Claessens
    • Kill off telepathy-core/telepathy-python/src/client.
    • Kill off fully-qualified property names used in channel requests
    • Since we are breaking tp-glib API/ABI, consider removing its deprecated APIs and some guarantees:
  • 5.97 -- test API/ABI breakage mechanisms
    • Rename the spec namespaces to vX and ensure that the mechanisms for demanding a restart on spec version mismatches work (make no other spec changes here)
  • 6.0 -- telepathy-not-1.0
    • Copy-paste code into one big git tree (no submodules going forward: they're far too much of a pain in the ass to work with. Don't make any attempt to preserve history: just refer everyone to the commit id of each submodule that was imported)
    • rename the spec namespace to vY just for fun.
  • 6.x -- things that would be nice to happen, but shouldn't block 6.0 from happening (?)
    • GDbus rewrite of tp-glib
    • Rename the spec namespace again, and delete all of the deprecated spec stuff.

  • 7.0 -- Things that would be nice to do API but may not actually happen

  • How long do we use submodules for, or do we force everyone to port all of their changes to telepathy-core by hand, from the first day of the project?

  • What do we do with the media streaming stuff? Does tpfs get included in tp-core?

  • I'm not quite sure how the mechanism for breaking the tp-glib-dbus apis are supposed to work. Here are a few proposals:

    • Make each CM author #include , and sed all of their source code to update from version X to version Y.
      • Same as above, but if the channel interface hasn't changed between vX and vY, generate which #includes . This would avoid too many bullshit sed commits for unchanged files, and encourage users to actually check what's changed on a per-file basis rather than blindly sedding and hoping for the best.
    • Let CM authors #include as long as they have defined the macro TP_DBUS_VERSION=X. This would let CM writers simply check their code for compat by hand and bump the version number to assert that it's all correct.
      • Same as the above, but (e.g.) #define tp_svc_channel_interface_* so that each function only produces a compiler warning if its semantics has been broken between version X and version Y and it is actually used (more fine-grained than the header approach). Things that I (alsuren) don't think will ever happen:

  • Killing off the enums (xclassens http://lists.freedesktop.org/archives/telepathy/2011-June/005540.html).