[Standards] disco-publish

Peter Saint-Andre stpeter at stpeter.im
Fri Apr 18 19:58:11 UTC 2008

Joe Hildebrand wrote:
> On 4/18/08 3:47 AM, "Ralph Meijer" <jabber.org at ralphm.ik.nu> wrote:
>> Hmm, considering that I find the node namespace to be shared among disco
>> and pubsub, I didn't expect this particular example. For example
>> considering the example from XEP-0030:
>>         <iq from='kinglear at shakespeare.lit/throne'
>>             id='publish1'
>>             type='set'>
>>           <query xmlns='http://jabber.org/protocol/disco#items'
>>                  node='jabber:iq:kids'>
>>             <item action='update'
>>                   jid='cordelia at shakespeare.lit'
>>                   name='Cordelia'/>
>>             <item action='update'
>>                   jid='goneril at shakespeare.lit'
>>                   name='Goneril'/>
>>             <item action='update'
>>                   jid='regan at shakespeare.lit'
>>                   name='Regan'/>
>>           </query>
>>         </iq>
>> This should result in the list of three items to show up when sending a
>> disco info query to the node 'jabber:iq:kids'. So I was expecting that
>> one would publish those items to the 'jabber:iq:kids' node.
> I think you're right here.  The main use case for disco publish was the
> now-superceded XEP-119; pointers to pubsub nodes for extended presence.  As
> such, it may be that the entire concept of disco publish is no longer
> required; it's all just straight PEP.

There is still the usecase of wanting to know which rooms are created at
a MUC service after you retrieve the list on login.

>> I also want to point out again that automatic subscriptions through Caps
>> are currently defined such that when you advertise to support a
>> particular namespace+notify, you will get notifications of all items
>> that carry payload in that namespace, *whatever the NodeID*.
> Whoa.  Guess I should have read the XEP-60 changes more carefully.  That was
> not the original intent.  It may be that it is better, however.  For
> example, it solves the "I publish two blogs" problem, at the expense of two
> different clients not necessarily knowing which node has which semantic
> meaning.



Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080418/cb499536/attachment.bin>

More information about the Standards mailing list