[Standards] pubsub/pep auto-creation

Rachel Blackman rcb at ceruleanstudios.com
Thu Mar 22 16:24:46 UTC 2007


> These seem to be more generic publish-subscribe features to me, and  
> were
> the use cases that were deemed too complex when we started out this
> whole PEP thing in the first place.

The argument for PEP, as I recall, was not that the publication flow  
itself was necessarily too complex, but that pubsub was just plain  
overkill for that sort of a case.

With pubsub, two different clients of the same user might publish to  
two entirely different pubsub services.  Moreover, if I logged in  
with a client other than the one I had subscribed to a node with, I  
might not know what the node meant.  It was entirely up to the / 
client/ to maintain a mapping of node-to-jid for every single pubsub  
node it cared about.  That's fine for more generic cases, even though  
it flies in the face of everything we've ever talked about in terms  
of 'simple clients, complex servers.'

There was no sensible 'this node = this jid' mapping.  It was easy to  
see 'oh, this romeo-tune-pubsub' node is a User Tune Data thing, but  
not to know what jid it meant if you hadn't subscribed to it on that  
client or if you'd lost your pubsub mappings due to a reinstall or  
whatever (especially since it wasn't like clients were necessarily  
naming machine-generated nodes in such a human-readable fashion).  We  
had all kinds of personal 'publish' XEPs which basically were never  
getting adopted because the overhead was so high, especially since at  
least a few people were trying to come up with ad-hoc manners of  
storing pubsub subscriptions in the per-server private XML storage,  
and... it just wasn't pretty.

During that, it was pointed out that XMPP already has a service which  
responds on behalf of the user at the user's JID -- namely, the  
server when you send a request without a resource.  For pubsub things  
that are tied to a specific user, PEP solves /all the major problems/  
and massively lowers the bar to adoption of any PEP-based XEPs.  (As  
soon as servers support it, anyway.)

This is *one* situation where the PEP specification is not ideal if  
we want to reduce the amount of traffic flying back and forth.  One.   
The PEP specification on the whole still solves the problem it's  
meant to solve in a way that is orders of magnitude better than the  
full pubsub specification. ;)

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/





More information about the Standards mailing list