Replies on a few points... On Tue, 2011-05-31 at 10:01 +0200, Xavier Claessens wrote: > I'm a bit scared about merging in the same repository, especially > tp-glib and tp-qt4. They do not have the same person hacking on them, > not the same priorities and schedule. For example tp-qt4 would currently > be driven by meego (and KDE?) releases, while tp-glib by GNOME releases.
This is the point of also introducing time-based releases at the same time, so that whoever is bringing a feature into Telepathy (for Qt4, Glib, or both) can just do it in one branch, crossing backend/spec/binding, and know when it can be expected to appear in the next Telepathy release. This allows a lot more certainty than the current situation, where you have to chase/beg/etc separate module maintainers for review and release, which is very time-consuming and unpredictable. > > 3. Include version numbers in D-Bus interface names. > > Would that version be a requestable property, so Empathy could request a > channel implementing Message iface version 0.5 and if CM only implements > 0.4 then the channel request fails and empathy could tell "sorry please > upgrade your CM"? Or am I missing the point? No, it would be, im.telepathy.v12.* on D-Bus would change to im.telepathy.v13.* because some methods have gone away. This means for a running component, chunks of Telepathy functionality (eg all of the CMs and all of the handlers) simply disappear when you upgrade tp-glib/tp-qt4 on your system. Note there is something important we have to do here: make a mechanism for clients and CMs to autogenerate their .client / .manager files correctly. Upgrades therefore require a Telepathy shutdown/restart. In practice, this works so badly at the moment (MC doesn't detect new handlers, etc) that I don't see this as a real regression. To improve the UX we would simply have something which detects this situation and provides a reconnect button, in the same way that Firefox or Linux kernel updates are handled on modern distros. > But what if the CM does > not support the new "Foo" with extra args? I guess the high-level > binding would require a specific version of the interface, and if the CM > implements an older version, we pretend the interface is not implemented > at all, so the feature would not be supported? The other solution is to > include all CMs into that big repository as well... not sure it's a good > idea... What happens is, that CM just stops compiling with this version of Telepathy until someone fixes it. The reality / expectation is that you have to remain closer to the Telepathy project to maintain a connection manager effectively. In practice if we introduce a new API feature in order to support a UI (FooDetailed) we have to go and fix all of the CMs we care about. This just turns the "subtle regression and bitrot" situation we have now into "very blatant build failure - buildbot goes red and someone must fix". > > Similarly, telepathy-glib and telepathy-qt4 both contain API that > > depends on recent, specific versions of Mission Control, and yet do not > > formally depend on those versions of MC. And telepathy-logger bindings > > are out of tree for both due to API stability concerns. So potentially > > more controversially: > > > > 5. Merge Mission-Control and Telepathy-Logger into the One Big > > Telepathy Module. > > Why tp-logger? The logger is a client as any other user of tp-glib > high-level API, no? Empathy communicate with the logger via a C api, not > dbus interface AFAIK, no? For MC it is the same as with CM, if we > include MC we should include all CM as well, no? No, I think in reality we never expect to have any other MC implementations, whereas we expect (design) to have many CMs. It took us long enough to arrive at one working MC implementation and I can't see any reason/incentive to write another any time soon. Certain features require crossing between MC, spec and client libraries already - eg the "just send one message" API which was added to TpQt4 recently. The logger is a little more debatable but there are already glib and Qt4 APIs for the logger functionality - I think the delicate handler/observer dance is already subtle enough that as a project we should aim to deliver a higher-level conversation API that just takes care of history, using the logger, rather than forcing client developers into understanding this strange corner of the spec and message IDs and stuff. > > Then we would tag, Chromium-style, a Telepathy major release every six > > weeks (say), which would contain the Glib binding, the Qt4 binding, > > Mission Control and the logger, all known to implement compatible D-Bus > > APIs. This would get rid of the tendency to delay releases to sneak one > > last feature in (as we had for the stable branches recently): missing > > the window wouldn't be critical, because it rolls around regularly and > > frequently. > > I also think we need more predictable stable/dev cycles and make all tp > components sync on that. Right, we'd have merge windows / stabilisation windows to go along with the time-based releases. > > • telepathy-glib-dbus-N (for integer N), the generated code for major > > version N of the D-Bus API. > > Do we want to expose that lib? I think it should be only internal into > tp-glib high-level. Or do you think we should still let Empathy use that > lib directly to experiment even if we do not give any ABI stability > guarantees? The CMs would likely use this low-level library - I'm not sure I agree it would change name per D-Bus interface version - I think it just breaks ABI in lockstep with the D-Bus API. > 1) I think it is important to get generated spec documentation online > more quickly, maybe setup a hook in git repository that rebuilds and > publish online at each commit? Would have a page spec-stable and > spec-dev? I don't think it's that important because I think nobody other than us uses the spec any more, partly because it has so much deprecated stuff in that it's now incomprehensible if you're not a Telepathy developer. We should focus on what our end-users need, well-documented and understandable client library APIs. > Regards, > Xavier Claessens. Regards, Rob -- Robert McQueen +44 7876 562 564 Director, Collabora Ltd. http://www.collabora.co.uk _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
