[PubSub] Questions about pubsub/pep
stpeter at stpeter.im
Thu Apr 16 16:14:12 CDT 2009
On 12/21/08 7:09 PM, Eric Butler wrote:
> Hey everyone,
> I'm working on a project using pubsub/pep and have a few questions.
> Should pep nodes be returned in the result of a disco#items query on a
> bare JID? Section 5.2 of XEP-0060 makes it sound like this should be the
> case, but it's not completely clear, and ejabberd does not return them.
> If not, what's the correct way to get a list of your pep nodes?
> Affiliations request?
One of the points of PEP is that you don't need to go through the whole
dance of service discovery and explicit subscription to nodes. Instead,
we essentially have well-known nodes (via specs like XEP-0118) and you
can be guaranteed that such a node is "reserved".
> XEP-0163 section 6.1 says that a PEP server should return the
> pubsub<feature>s on behalf of a user for a disco#info request, however
> ejabberd 2.0.2_2 does not. Is this an implementation bug, or am I
> misunderstanding the specifications?
IMHO the relationship between disco and PEP (or pubsub in general) on
this point still needs to be clarified. IMHO it would be best for the
server to return the nodes, even though that's not the preferred way for
a contact to figure out your PEP nodes (because the contact should just
magically start receiving notifications if it puts the special bits into
its entity capabilities data).
> Here's what I do get:
> <iq to='eric at extremeboredom.net'
> <query xmlns='http://jabber.org/protocol/disco#info'/>
> <iq from="eric at extremeboredom.net" type="result"
> to="eric at extremeboredom.net/Psi" id="disco1" >
> <query xmlns="http://jabber.org/protocol/disco#info">
> <identity category="pubsub" type="pep" />
> <feature var="vcard-temp" />
> <feature var="http://jabber.org/protocol/commands" />
Aha, so you're trying to discover whether you've already created a node
for a given PEP payload type? That seems like a useful thing. :) For
that purpose, proper disco support seems useful. So file a bug against
your favorite pubsub server codebase. :)
> How are clients expected to behave when they see a pubsub/pep
> <identity>? What's the purpose of this, assuming you also get
> pubsub-related <feature>s?
In general, identities used to be more important in the early days of
XMPP because until service discovery we didn't have features, only
identities (look at XEP-0094). When we defined XEP-0030, we added a way
to discover features but retained the concept of identities. At this
point we really don't use identities very much -- client behavior is
tied in to features, not identities.
> XEP-0060 mentions that events can be "transient" or "persistent", could
> someoe please clarify what these are? I didn't find it very clear,
> though I may have missed the definitions.
More history. :) In the long discussions leading up to XEP-0060, some
developers insisted that pubsub was pure eventing and that you'd never
need or want to store items at a pubsub node. Other developers insisted
just as passionately that they wanted the ability to get old items if
they missed a notification or whatever. As a result, we made this a
matter of configuration (basically punting to gain consensus). So a
"transient node" is a node where items are not stored, and a "persistent
node" is a node where items are stored. (The terms don't apply to the
nodes themselves, they apply to the items published at those nodes.)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/pubsub/attachments/20090416/2729e04f/attachment.bin
More information about the PubSub