[Standards-JIG] Jabber external components: going out of style
melo at co.sapo.pt
Thu May 18 00:25:28 UTC 2006
On May 18, 2006, at 12:52 AM, Jean-Louis Seguineau wrote:
> Come on Pedro, this is a little far fetched. You can always retrieve a
> roster from a component through a jabber:iq:roster query. You can
Of course you can't. Let me rephrase that: the server I use doesn't
I wish it did :)
And although I would love to have some protocol to have access to the
roster in a standard way, I believe that components should not have
access, for security reasons. At least by default.
But let's assume that you could. I can fake the request, but given
that those protocols use the 'from' to identify the roster I want,
where would the server get the information to route the answer back
For example: my component comp.domain.com sends this:
<iq type="get" id="1" to="domain.com" from="user at domain.com">
<query xmlns="jabber:iq:roster" />
There is no information on that stanza to route back the answer to
I suppose you could try to="user at domain.com"
from="comp.domain.com"... That would be enough, but doesn't work on
How would you do it?
Same issue for privacy settings.
> retrieve privacy settings through jabber:iq:privacy. In a component
> implementation, you have more leeway on the trust level and features
> agreement between server and component. You would need to push your
> component into every user's roster at the server level, so it knows
> every body's presence, and you have pretty much you PEP component
Yes, I forgot the need for presence mirroring. Placing your component
in the roster would work, but I find it clunky. I would prefer some
sort of "subscribe to this xpath filter"-protocol that an external
component could use to request a copy of everybody presence :)
> Just add namespace based routing to get the PEP IQs where they
> belong. This
> is internal to the server, and I know some server do it.
Yes, I know. the one we use does that. Works very well. But it is a
private API, not a public one.
> If your current server does not support this approach, you would
> need to
> request these features to be added ;) It is not linked to XMPP, but
> more to
That's my point: I can do this, implement a PEP component, with my
current server. But I cannot share that PEP component with other
server implementations and therefore save everybody else from having
to implement it again. The fact that to do this I have to use private
API tied to a particular implementation is the part I don't like.
The question becomes: is there a real need for standard ways for an
external component to get to roster information and other parts of
the server? maybe a jep to simulate a client connection without
Right now, doesn't seem so. ejabberd, wildfire, and xcp (I guess the
major server now?) are all happy implementing PEP on there own...
HIId: Pedro Melo
SMTP: melo at co.sapo.pt
XMPP: pedro.melo at sapo.pt
More information about the Standards