[jdev] jabberd2 coponent protocol proposed extension

[Pedro Melo]

Hi,

On Jul 20, 2007, at 11:45 PM, Tomasz Sterna wrote:

> I'm going to extend jabberd2 component protocol to allow components
> access to user roster and presence information.
> (Mainly for PEP and transports :-)
>
> But before I do it I wanted to make a sanity check if the idea makes
> sense.
> My proposed changes are described on
> http://jabberd2.xiaoka.com/wiki/ComponentProtocol
>
> Any comment is welcome.

I've talked with some of the ejabberd folks about this.

I'll read the above URL later, but my first idea was to make your JSM/ 
Router a PubSub component, with well known nodes for user presences,  
roster changes, and other useful information.

This would mean that even XEP-0114 components could be extended to  
ask for that kind of information.

I don't have any problem replacing XEP-0114, mainly to add a decent  
XMPP-style handshake at the top. I'll look at your J2 component  
protocol also.

In a email I sent ejabberd people and others some weeks ago I wrote  
this:

---- begin paste ----

Apart of the initial handshake, that should be improved to something  
much more like XMPP handshake (but IMHO, with TLS as an option),  
there are three areas where I would like to see some improvements:

  * addressing

the component should use the advertised name in the initial handshake  
as the destination address for all of the following protocols

  * namespace routing

It should be possible for a external component to tell the server  
that he will be responsible for namespace X for domains A, B and C.

For example, a component connecting to example.com server could:

  <iq type="set" to="example.com" from="component.example.com" id="1">
     <query xmlns="urn:xmpp:ext:register-route">
       <ns>vcard:temp</ns>
       <host>example.com</host>
       <host>example.net</host>
    </query>
  </iq>

This would add to the disco#info reply of example.com and .net the  
feature vcard:temp and all IQs with that namespace that would require  
a server response (directed to the domains themselves or to any bare  
jid inside that domains) would be routed to the component.

* the JSM as a PubSub service

Lots of components require access to all of the user presences,  
including presences sent to him by elements on his roster. Also  
access to the roster itself, and roster updates would be helpful for  
certain protocolos (PEP for example).

This could be implemented by making the JSM act as a PubSub service.  
An external component would subscribe to a domain like this:

<iq type="set" to="example.com" from="component.example.com" id="1">
   <pubsub xmlns="http://jabber.org/protocol/pubsub">
     <subscribe node="example.com#presence_incoming"  
jid="component.example.com" />
   </pubsub>
</iq>

<iq type="set" to="example.com" from="component.example.com" id="1">
   <pubsub xmlns="http://jabber.org/protocol/pubsub">
     <subscribe node="example.com#presence_outgoing"  
jid="component.example.com" />
   </pubsub>
</iq>

<iq type="set" to="example.com" from="component.example.com" id="1">
   <pubsub xmlns="http://jabber.org/protocol/pubsub">
     <subscribe node="example.com#roster" jid="component.example.com" />
   </pubsub>
</iq>

Each node is in the form "domain"#"items". "domain" could be "*"  
meaning all domains configured for C2S connections.

There will be 3 (possible 4) "items". if a specific item is  
subscribed, the matching stanzas would be sent to the component.

  * presence_incoming: presences received from the C2S module - all  
the presence changes from our client;
  * presence_outgoing: presences sent by buddies on the user roster;
  * roster: the initial roster get result, as all roster pushes would  
be Cc'ed to the component.
  * (optional) all: all of the above.


  * Roster manipulation

It would also be interesting to allow roster manipulation from a  
component. I'll expand this soon... I want to see how to leverage  
roster exchange XEPs.


That my initial brain dump.

I'm specially insterested in the namespace routing feature, given  
that it allows us to extend the core router easily.


--- end paste ---

This was sometime in June.

Best regards,
-- 
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt