| Summary: | WockyPepService::changed should include the <items> node (or more) | ||
|---|---|---|---|
| Product: | Wocky | Reporter: | Will Thompson <will> |
| Component: | General | Assignee: | Telepathy bugs list <telepathy-bugs> |
| 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/wjt/wocky.git/log/?h=45400-pep-service-rummage-for-items | ||
| Whiteboard: | review+ | ||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 33911 | ||
Here's a branch. My only objection to this branch is that XEP-0060 suggests that the last item might be a better choice than the first, although tbh it's pretty vague, and I'm quite prepared to believe that in the real world, nobody publishes multiple items at once. Care to review Bug #43992 while you're in Wocky-land? (In reply to comment #2) > My only objection to this branch is that XEP-0060 suggests that the last item > might be a better choice than the first, although tbh it's pretty vague, and > I'm quite prepared to believe that in the real world, nobody publishes multiple > items at once. PEP is a subset of PubSub. Every PEP-based XEP publishes one item per node. Every PEP implementation in Gabble publishes and looks for the first item. (In reply to comment #3) > PEP is a subset of PubSub. Every PEP-based XEP publishes one item per node. > Every PEP implementation in Gabble publishes and looks for the first item. OK, I'm convinced. Thanks, merged. |
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.
WockyPepService::changed fires when a <message> stanza matching the following is received: '(', "event", ':', WOCKY_XMPP_NS_PUBSUB_EVENT, '(', "items", '@', "node", priv->node, ')', ')', In practice, PEP change notifications always contain something like this: <event xmlns='http://jabber.org/protocol/pubsub#event'> <items node='http://jabber.org/protocol/tune'> <item> <tune xmlns='http://jabber.org/protocol/tune'> <artist>Gerald Finzi</artist> <length>255</length> <source>Music for "Love's Labors Lost" (Suite for small orchestra)</source> <title>Introduction (Allegro vigoroso)</title> <track>1</track> </tune> </item> </items> </event> <event xmlns='http://jabber.org/protocol/pubsub#event'> <items node='http://jabber.org/protocol/geoloc'> <item id='d81a52b8-0f9c-11dc-9bc8-001143d5d5db'> <geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'> <accuracy>20</accuracy> <country>Italy</country> <lat>45.44</lat> <locality>Venice</locality> <lon>12.33</lon> </geoloc> </item> </items> </event> It would be much more useful for code listening for ::changed if WockyPepService did the hard work of drilling down to the <item/> node (if any) for them—or possibly even to its child—and passed the relevant WockyNode * to the signal handler.