The ytstenut spec has an example of a status XML node: <ytstenut:status version='1.0' from-service='com.meego.BestestFriendApplication' capability='yts-caps-video' activity='yts-activity-play' uri='some random youtube url' volume='0.75'> <ytstenut:description xml:lang='en-GB'> Playing a video about colour-based optical illusions. </ytstenut:description> </ytstenut:status> and mentions that the value of the capability attribute should be like those mentioned in section 3.7.1, all of which are of the form "yts-caps-..." with no prefix. That's sensible: ytstenut statuses always pertain to a capability, not a transfer protocol, status or alike. The C2S Ytstenut stack which gabble is a part of encapsulates these nodes inside PEP events. PEP event autosubscription works by advertising a XEP-0115 feature token of the form "<node-name>+notify", where <node-name> is like a "topic", a node on which events are published. Ytstenut status push subscriptions are to capabilities; hence the node name must include the capability. But the node name must be globally unique. By prefixing the capability with "urn:ytstenut:capabilities:", a globally unique node name is attained. This is what the Gabble-based stack uses as the PEP event node name. However, this is where the gabble plugin gets it wrong: it overrides whatever "capability" attribute was in the status XML passed to it with the prefixed version. Thus, it'd send the example status node from the spec with "capability='urn:ytstenut:capabilities:yts-caps-video'". Should we change the spec, or should we change gabble? I don't think we need the redundant prefixes in the XML, so I vote for fixing gabble.
> capability. But the node name must be globally unique. By prefixing the > capability with "urn:ytstenut:capabilities:", a globally unique node name is > attained. This is what the Gabble-based stack uses as the PEP event node name. > This brings an another possible issue: the PEP node is transient, so it will only ever contain one event at a time. But as the PEP node is capability-wide, multiple services on a given full JID will override each other's statuses if they announce statuses on the same capabilities. So if we want to support many services with overlapping capabilities separately announcing a status, this must be addressed as a separate spec bug.
Off the cuff I'd agree to better cut down on redundancy. Need to look at it in more detail though (test case).
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.