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|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. * 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|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): [[!format txt """ ${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|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|https://bugs.freedesktop.org/show_bug.cgi?id=26205#c19]]) * Stop [[TpContact|TpContact]] from taking a strong ref on its [[TpConnection|TpConnection]] (See [[https://bugs.freedesktop.org/show_bug.cgi?id=26205#c26|https://bugs.freedesktop.org/show_bug.cgi?id=26205#c26]]) * Stop emitting "invalidated" signal from [[TpProxy|TpProxy]]'s dispose * 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|TpHandle]]? -- (wjt [[http://lists.freedesktop.org/archives/telepathy/2011-June/005556.html|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 , 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|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|https://bugs.freedesktop.org/show_bug.cgi?id=37803]]) to use GEnum to link the enums and strings more conveniently.