Summary: | Support addressing in TpBaseProtocol | ||
---|---|---|---|
Product: | Telepathy | Reporter: | Eitan Isaacson <eitan.isaacson> |
Component: | tp-glib | Assignee: | Andre Moreira Magalhaes <andrunko> |
Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
Severity: | normal | ||
Priority: | medium | Keywords: | patch |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
URL: | http://cgit.collabora.com/git/user/andrunko/telepathy-glib.git/log/?h=protocol-addressing | ||
Whiteboard: | review+ after next spec release | ||
i915 platform: | i915 features: | ||
Bug Depends on: | 32690 | ||
Bug Blocks: | 32692, 41789 |
Description
Eitan Isaacson
2010-12-27 16:22:53 UTC
(This can't be merged until the undrafted spec has landed and been released.) I'm not really sure that Addressing should be in the TpBaseProtocol vtable: we're running out of slots, and Addressing doesn't seem particularly fundamental. Maybe it should be a GInterface (see how TpBaseContactList does its optional functionality, for instance). I could be persuaded either way. > + * TpBaseProtocolGetAddressingDetailsFunc: ...Dup... rather than Get, really. > + * Since: 0.13.11 No such version yet, so who can say what'll be in it? 0.13.UNRELEASED, please. > TpBaseProtocolAddressingNormalizeVCardAddressFunc I don't think the word Addressing adds value here. >+ * TpBaseProtocolAddressingNormalizeUriFunc: Likewise, and I'd also prefer the acronym capitalized: TpBaseProtocolNormalizeURIFunc. > + G_IMPLEMENT_INTERFACE (TP_TYPE_SVC_PROTOCOL_INTERFACE_ADDRESSING, > + addressing_iface_init)); That trailing semicolon isn't needed, and causes an empty statement to appear, which breaks some compilers. > + if (tp_strv_contains ((const gchar * const*) self->priv->interfaces, const * (with a space) (In reply to comment #1) > (This can't be merged until the undrafted spec has landed and been released.) > > I'm not really sure that Addressing should be in the TpBaseProtocol vtable: > we're running out of slots, and Addressing doesn't seem particularly > fundamental. Maybe it should be a GInterface (see how TpBaseContactList does > its optional functionality, for instance). I could be persuaded either way. That would be a good use of GInterface, I was having a hard time taking up two more precious slots. Plus, I don't like the get_details function, I think they should each be a separate one, but I was conserving slots. Anyway, the HEAD has this implemented as a GInterface along with all the other review bits you gave. Ok, I used this work in order to implement bug #41789. I rebased/fixed conflicts Eitan's changes on top of current upstream master and the changes can be found at URL. Patches with substantial changes from you shouldn't really be --author=Eitan any more, IMO. Attribute such patches to yourself, with "Based on a patch from Eitan Isaacson <...>" in the commit message? > Undraft Protocol.Interface.Addressing. Not really valid, but will go away when this branch is rebased onto a version of tp-glib with a version of tp-spec where P.I.A is undrafted. > Make Protocol.Interface.Addressing functionality a GInterface. I'd have vaguely preferred this one squashed into the previous commits - you'd have to split it, since half of it is squashed into "add the feature" and the other half into "... and add a test". Review in detail in a moment (I'll review a squashed version rather than using gitweb). reassigning to Andre The implementation looks fine; some naming/documentation/g-i issues. +/** + * TpBaseProtocolGetSupportedVCardFields: Needs a Returns: line. Did you build this branch with gtk-doc? Did it tell you you were missing this? The Returns: line gives you a chance to say "a list of vCard fields in lower case, e.g. [x-sip, tel]" or whatever - SIP makes a great example for this sort of thing, because it typically supports both SIP and telephony, and its vCard field and URI scheme don't have the same name. It's actually Returns: (allow-none) (out) (transfer full): ... in order to have the g-i annotations right, I think. Neither you nor Eitan fixed this: > > + * TpBaseProtocolGetAddressingDetailsFunc: > > ...Dup... rather than Get, really. Also, I think a typedef for a function pointer should generally say ...Func at the end (this one did in Eitan's initial branch, not sure what happened to that). +/** + * TpBaseProtocolGetSupportedURISchemes: All comments about SupportedVCardFields apply here. Again, consider using SIP as your example, to have [sip, sips, tel]. (In reply to comment #6) > The implementation looks fine; some naming/documentation/g-i issues. > > +/** > + * TpBaseProtocolGetSupportedVCardFields: > > Needs a Returns: line. Did you build this branch with gtk-doc? Did it tell you > you were missing this? > > The Returns: line gives you a chance to say "a list of vCard fields in lower > case, e.g. [x-sip, tel]" or whatever - SIP makes a great example for this sort > of thing, because it typically supports both SIP and telephony, and its vCard > field and URI scheme don't have the same name. > > It's actually Returns: (allow-none) (out) (transfer full): ... in order to have > the g-i annotations right, I think. > > Neither you nor Eitan fixed this: Done, used the same annotation above. > > > + * TpBaseProtocolGetAddressingDetailsFunc: > > > > ...Dup... rather than Get, really. > > Also, I think a typedef for a function pointer should generally say ...Func at > the end (this one did in Eitan's initial branch, not sure what happened to > that). Actually this has changed now and does not exist anymore. Updated telepathy-glib-sections.txt accordingly. > +/** > + * TpBaseProtocolGetSupportedURISchemes: > > All comments about SupportedVCardFields apply here. Again, consider using SIP > as your example, to have [sip, sips, tel]. Done Also fixed a bug in the protocol-objects test. (In reply to comment #7) > > > > + * TpBaseProtocolGetAddressingDetailsFunc: > > > > > > ...Dup... rather than Get, really. No longer exists, but TpBaseProtocolGetSupportedVCardFields and TpBaseProtocolGetSupportedURISchemes have the same issue... > > Also, I think a typedef for a function pointer should generally say ...Func at > > the end ... and also this one. (In reply to comment #8) > (In reply to comment #7) > > > > > + * TpBaseProtocolGetAddressingDetailsFunc: > > > > > > > > ...Dup... rather than Get, really. > > No longer exists, but TpBaseProtocolGetSupportedVCardFields and > TpBaseProtocolGetSupportedURISchemes have the same issue... True, done. > > > Also, I think a typedef for a function pointer should generally say ...Func at > > > the end > > ... and also this one. Done. r+ after the next spec release comes out. Updated branch with latest changes in Proto.I.Addr (rename NormalizeURI to NormalizeContactURI). It will be in the next tp-glib release. Released in 0.17.2 |
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.