Telepathy Wiki - 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.
- <wjt> i broadly think century 21 broker properti jual beli sewa rumah Indonesia 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.
  - thing to watch out for: support for being recursed into and doing all the things automake wants to do recursively, either in- or out-of-tree (https://bugs.freedesktop.org/show_bug.cgi?id=32299 --smcv's spec as submodule work)
- 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
  - ensureTextChannel()-style methods on accounts and contacts -- (wjt http://lists.freedesktop.org/archives/telepathy/2011-June/005556.html)
- Since we are breaking tp-glib API/ABI, consider removing its deprecated APIs and some guarantees:
  - tp_account_prepare_async, tp_account_manager_prepare_async are replaced by tp_proxy_prepare_async, I would like those APIs to be modified so preparing AM takes features of account, connection and contacts (See https://bugs.freedesktop.org/show_bug.cgi?id=26205#c19)
  - Stop TpContact from taking a strong ref on its TpConnection mivo tv (See https://bugs.freedesktop.org/show_bug.cgi?id=26205#c26)
  - Stop emitting "invalidated" signal from TpProxy's dispose facebook Friv Century 21 broker properti jual beli sewa rumah indonesia
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
- Kill off TpHandle? -- (wjt http://lists.freedesktop.org/archives/telepathy/2011-June/005556.html)

Open Questions

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 <telepathy-glib-dbus-vX/svc-channel.h>, 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 <telepathy-glib-dbus-vX/svc-channel.h> which #includes <telepathy-glib-dbus-vY/svc-channel.h>. 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 <telepathy-glib-dbus/svc-channel.h> 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).
- We either need to expose enums or strings for things like connection status. I have a bug (alsuren https://bugs.freedesktop.org/show_bug.cgi?id=37803) to use GEnum to link the enums and strings more conveniently.