[Telepathy] Telepathy 1.0 will never happen
David Laban
alsuren at gmail.com
Mon Jun 6 19:34:36 PDT 2011
I have tried to solidify the discussion here and brainstormed an action plan.
I hijacked http://telepathy.freedesktop.org/wiki/Roadmap to do it (which
otherwise hasn't been updated since 2009).
If you see any obvious errors (or I have missed something from one of the
threads) jump in and fix the wiki (or reply here). I have copy-pasted the Open
questions section here, so that people can add their $0.02 more easily.
== 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, right from the first day of the
project?
* What do we do with the media streaming stuff? Does tpfs get included in
tp-core too?
* 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 in a single header.
* 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 per-header approach. Does anyone here have the
macro-fu to do this kind of thing without looking it up?)
I will be around in #telepathy (Montreal time) for quicker feedback, and I
will try to hack together an all-in-one telepathy-core that builds this week
(as a first step to make sure the approach is vaguely sane). My autotools-fu
is not as strong as some (and my CMake-fu is pretty feeble), so if someone
else wants to take the lead on this part of the project and hand me the easy
tasks, I won't complain.
David.
More information about the telepathy
mailing list