[Standards] Re: compliance levels for 2008
jd.conley at coversant.net
Mon May 14 19:17:28 UTC 2007
I agree that Component protocol should not be included in the suite. The
method used to connect components is going to vary greatly depending on
implementation. This gets especially weird when you start federating
services in combination with load balancing, clustering, guaranteed
Also, the component protocol needs to be updated to be more XMPP
friendly and secure (AKA use stream:features and SASL), as well as be
coupled with a suite of protocols for performing common tasks component
writers crave like: GetAllBareJIDResourcePresences,
GetAllAvailableResources, ChangePresenceOnBehalfOfResource. We also need
the ability to hook into common events like: ResourcePresenceChanged,
RosterChanged, etc. Currently these types of actions/events are all
built with custom protocols in each implementation.
> -----Original Message-----
> From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org]
> Behalf Of Peter Saint-Andre
> Sent: Monday, May 14, 2007 11:51 AM
> To: XMPP Extension Discussion List
> Subject: Re: [Standards] Re: compliance levels for 2008
> Mridul Muralidharan wrote:
> > Peter Saint-Andre wrote:
> >> Mridul Muralidharan wrote:
> >>> Why is component protocol required ?
> >>> I thought it was historical and informational ...
> >> Would it help to change it to Standards Track? There has been talk
> >> about working on a new component protocol but the existing one is
> >> widely implemented and deployed, and is the only standard way to
> >> connect external components to servers.
> >> Peter
> > It is used, true - but is there any reason why a intermediate
> > server should support it ?
> > For example, pubsub/muc/jud/something_else could be implemented
> > the server without requiring external components.
> I see your point. Let's say MUC is required. How you implement it in
> your server codebase is up to you. If you don't support MUC
> you'll need to support it via external component. But that's an
> implementation decision, not something that we need to require in the
> Intermediate IM Server definition.
More information about the Standards