From the definition of GetContactAttributes(): > It is an error to request interfaces that are not supported by this > Connection (i.e. mentioned in the ContactAttributeInterfaces > property). > > | This makes it possible to distinguish between interfaces for which > | the Connection has nothing to say (e.g. we don't know the avatar > | tokens of any of the contacts, so we omitted them all), and interfaces > | for which this API isn't supported. This is needlessly pedantic. If we had instead said that the CM must ignore interfaces which aren't supported on the Contacts interface, then client code that does care could still check ContactAttributeInterfaces to distinguish those two cases, and client code that doesn't care wouldn't have to mess around checking the list of interfaces it passes to GetContactAttributes().
Here is a branch for this spec change: http://git.collabora.co.uk/?p=user/wjt/telepathy-spec-wjt.git;a=shortlog;h=refs/heads/fd.o-27325-GetContactAttributes-tolerance Here is the HTML of the method's new wording: http://people.freedesktop.org/~wjt/telepathy-spec-fd_o_27325_GetContactAttributes_tolerance/spec/org.freedesktop.Telepathy.Connection.Interface.Contacts.html#org.freedesktop.Telepathy.Connection.Interface.Contacts.GetContactAttributes Here is a branch to make TpContactsMixin tolerant: http://git.collabora.co.uk/?p=user/wjt/telepathy-glib.git;a=shortlog;h=refs/heads/fd.o-27325-GetContactAttributes-tolerance Here is an untested branch to make telepathy-butterfly tolerant: http://git.collabora.co.uk/?p=user/wjt/telepathy-butterfly.git;a=shortlog;h=refs/heads/fd.o-27325-GetContactAttributes-tolerance
I think Rob was in favour of it being this fascist, but I can't remember why...
(In reply to comment #2) > I think Rob was in favour of it being this fascist, but I can't remember why... If so, I was wrong due to lack of any supporting rationale recorded, that any of us can remember, or that we can think of. I apologise, and give free leave to reduce fascism wherever possible in the interests of reducing roundtrips. The reason /may/ have been not being able to tell the difference between supported-but-not-known-for-this-contact versus not-supported. But for simple use cases, you don't care about this.
review+, in that case. Considering this to have been specmeet-approved since most of the usual specmeet cabal have been involved. Non-review-blocker: > + logger.debug("Ignoring unsupported interface " + interface) logger.debug("Ignoring unsupported interface %s", interface) is conventional (if called with more than one argument, logger methods interpolate their arguments into the first one as if via %).
Spec and tp-glib bits merged; butterfly bit cloned as bug 27374.
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.