[Standards-JIG] Jabber external components: going out of style

[Jean-Louis Seguineau]

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 always
retrieve privacy settings through jabber:iq:privacy. In a component based
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 about
every body's presence, and you have pretty much you PEP component done...
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.

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
implementation.

Jean-Louis
 

-----Original Message-----
Message: 8
Date: Wed, 17 May 2006 23:49:17 +0100
From: Pedro Melo <melo at co.sapo.pt>
Subject: [Standards-JIG] Jabber external components: going out of
	style
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <F4FFBADE-691E-4BD7-9CFE-E2C8B0E766E5 at co.sapo.pt>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Hi,

a small topic detour...

On May 17, 2006, at 10:53 PM, Richard Dobson wrote:
>> wouldn't xmpp:capulet/%s4134edd be a nicer encoding for instance?
>> you could even transfer it in a non-xmpp medium.
>
> no thats horrible and means the multicasting component is  
> completely tied into the jabber server and cannot be separated, in  
> jabber we usually try to use a distributed architecture, we  
> certainly dont tie specs down to prevent them from being able to be.

First, I agree with you. I don't like the xmpp: addresses.

But your argument is wrong. Recent JEPs are getting more and more  
integrated or tightly coupled with the server. One example: PEP. Its  
the current favorite for a lot of problems, and it's my favorite two.  
But an external component implementation is out of the question.

XMPP used to do a lot of things in a way that they could be  
implemented in an external component, so that if you had a great MUC  
implementation you could just reuse it on several servers.

Not anymore. To write a PEP component, I need to have access to the  
roster information (there is not standard protocol to do that), and I  
need to redirect to-server traffic to an external component (also no  
standard for that).

So yes and no: in jabber we usually tried to use a distributed  
architecture, but not any more.

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