[standards-jig] pubsub usability for avatars and similar stuff

Alexey Shchepin alexey at sevcom.net
Sun Jul 20 20:25:33 UTC 2003

Hello, Ralph!

On Sun, 20 Jul 2003 11:16:24 +0200, you said:

 RM> Yes, this is exactly the idea followed in JEP-0084. You need no structure
 RM> in your pubsub nodes like "home/server/user/avatar". Of course, you can
 RM> choose to write a pubsub component that does have some kind of structure,
 RM> but as mentioned earlier in this thread, a client just wants to a have a
 RM> node it can publish, too. Why should it care about the aesthetics of the
 RM> node id?

Because when human will discovery items in pub/sub service to manually
subscribe to something, he will see list of meaningless node names, so he will
need to retrieve items for each node to find what he need.  At least there can
be a way to request instant node with some prefix, e.g. if client will request
such node with name "avatar" and node already exists, then service will create
node "avatar3874623874623874"...

 RM> Querying the server via disco to find out where somebody's avatar node is,
 RM> seems natural. It can be the case that users want to store their avatar on
 RM> another server than their mood, so you have to query for this anyway...

BTW, imagine that pub/sub server where avatar is stored now not works and user
now use another pub/sub server.  How users that subscibed to his avatar will
know about that?  This looks like for what pub/sub is.  So why pub/sub not
defines such use case:

<iq type="set" from="pgm at jabber.org" id="create1">
    <pubsub xmlns="http://jabber.org/protocol/pubsub">
        <create node="generic/pgm-mp3-player"/>

I.e. no "to" attribute.  E.g. to subscribe to avatar address client can send

<iq type='set'
    from='romeo at montague.net/orchard'
    to='juliet at capulet.com'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <subscribe node='avatar-address'/>

instead of requesting it with

<iq type='get'
    from='romeo at montague.net/orchard'
    to='juliet at capulet.com'

More information about the Standards mailing list