dbus-glib is unable to emit 16-bit integers, so we can't comply with telepathy-spec in telepathy-glib. In practice, this means that our D-Bus API has never been what we claim, which is likely to cause problems for telepathy-qt4 (QtDBus is pickier about types). Even if this is fixed in dbus-glib, using that fact would be an ABI break in telepathy-glib. One possible solution is to declare that the API we implement in practice is the official one (by turning all our 16-bit integers 32 bits long), causing an ABI break in telepathy-qt4 (which is not yet considered stable anyway). This branch implements that, although it'll need updates for the current spec: http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/16bit
(I vote we just defer this yet more until we move to GDBus where it will hopefully fix itself.)
Actually, we're not moving to GDBus yet and this is trivially "fixed" if we just s/q/u/g. At the moment this is only used for IP socket ports, so, no harm done. Let's do this for next. I will cook a patch.
Yes, here it is. Czech it out.
Yes, please do, so this doesn't take another 3 years. + if self.dbus_type == 'q': + raise UntypedItem("Node referred to by '%r' has type 'q' which is unsupported " + "by dbus-glib; use 'u' instead" % self) Please complain about int16 too (I think it's 'n'). I think "if 'n' in self.dbus_type or 'q' in self.dbus_type" would be a better check, to catch things like an a(sq) not qualified by a tp:type too.
(In reply to comment #4) > Please complain about int16 too (I think it's 'n'). Done. > I think "if 'n' in self.dbus_type or 'q' in self.dbus_type" would be a better > check, to catch things like an a(sq) not qualified by a tp:type too. Good idea. I made these changes and pushed my updated commits. Thanks for the review.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.