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: [EMAIL PROTECTED]
XMPP: [EMAIL PROTECTED]
