[Standards] Proposed XMPP Extension: Stanza Repeaters

Peter Saint-Andre stpeter at stpeter.im
Mon Mar 17 22:03:41 UTC 2008


Nolan Eakins wrote:
> On Mon, Mar 17, 2008 at 12:28 PM, XMPP Extensions Editor
> <editor at xmpp.org> wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>>  Title: Stanza Repeaters
>>
>>  Abstract: This specification defines an XMPP extension that enables optimization of interdomain traffic that is intended for delivery to multiple recipients, using the concept of a stanza repeater.
>>
>>  URL: http://www.xmpp.org/extensions/inbox/repeaters.html
> 
> Thought I'd take a look at how this worked. My first question is: why
> are we sending stanzas to the repeater using <iq/>s? Why can't I
> create a repeater, using <iq/>s of course, and then begin sending
> stanzas directly to the repeater which then forwards them out to
> everyone?
> 
> Looking at the examples, it looks like the repeater service is giving
> each repeater a JID. Sending stanzas to it directly ought to work.
> Perhaps something like:
> 
>> Example 1. Stanza as sent to repeater
> 
>>    <presence xmlns='jabber:client'
>>              from='poweruser at example.net/foo'
>>              to='e4df4399642aed42b579b05dc5c663aee27d6ec4 at repeater.example.com'
>>              type='probe'/>

We had that in version 0.0.0.5. :)

The problem is that you can't send disco requests or other management
tasks to the repeater. But you could do that by sending those requests
to the repeater service and specifying the particular repeater you're
interested in.

Another thing is that the IQ semantics are helpful here -- the repeater
validates that it has sent all the stanzas and then sends you an IQ result.

> One problem is that all of the management use cases in the XEP would
> probably need to be changed so that repeating <iq/> stanzas is
> simpler. This is easily changed by making the repeater service's JID
> handle all management requests for individual repeaters.

Right.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- 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/20080317/0b5743d0/attachment.bin>


More information about the Standards mailing list