[Standards] Components

Matthew Wild mwild1 at gmail.com
Thu Feb 18 12:11:02 UTC 2010

On 18 February 2010 11:33, Dave Cridland <dave at cridland.net> wrote:
> I've been meaning to jot down some ideas on components for some time. Here's
> a largely unstructured list of ideas I'd like to float:
> 1) Components should authenticate with an ordinary jid.
> That is, if I run Spectrum, say, I'd have an acocunt
> spectrum at dave.cridland.net, and it'd authenticate "as usual" with that.
> This means that "Spectrum" is now addressable. Moreover, if I have multiple
> Spectrums - Spectra? - then they're individually addressable, and can even
> talk to each other if they want.

I'm not too keen on this for various reasons. Though it sounds very
similar to something Waqas has been plotting, have you been speaking
with him? :)

> 2) Components can request domains.
> Since components now don't innately authenticate with their domain as the
> jid, instead they request service for a domain. They can request more than
> one domain during their session, meaning that Spectrum no longer has 24
> zillion connections for each transport gateway it offers, but just the one
> per instance.

XEP-0225 allows this already.

> 3) Components can request domains *with options*.
> ... which allows them to ask for, for example, "msn.dave.cridland.net" to be
> routed to them, load balanced by the source jid with no failover.
> Of course, since component instances can now communicate via XMPP, failover
> should become easier, but that's another matter.

XEP-0225 could be extended very easily to allow this.

> 4) Components expose a common component interface.
> They can do this on their "real" jids, since those can't interfere with
> whatever interface the domain itself needs to offer.
> I was thinking in terms of various ad-hoc commands, whatever makes sense
> here.

I don't see that an entity on the network needs 2 addresses, or why
they would interfere. I believe Spectrum already (or plans to)
implement ad-hoc on the domain JID.

> 5) Servers expose a disco node to authorized users containing the component
> sessions' real jids.
> This provides a management hook-up for authorized users to obtain the list
> of component sessions and from there talk to them.

Unnecessary complexity.

> I think this leaves us with a few key things:
> a) "The component protocol" is, now, just the normal C2S protocol, with some
> extra bits, so in principle any off the shelf XMPP library can be made to do
> the basics with very little effort.

See, I've been thinking differently... that components would speak on
5269, and be viewed more as another (trusted) server. Just as in s2s
they could bind multiple domains.

> b) Components now open a single connection, reducing complexity, and can
> instruct the server on the correct configuration, reducing administrative
> pain.

As said above, 225 allows this already. Though I wouldn't mind
extending it to allow components to bind say...
msn.example.com/{resource} - this way each instance becomes

> c) We have a framework to build common management of components of all
> kinds, without risk of interfering with the interfaces actually exposed.

I don't see this as a problem worth the added complexity of fixing.

> Any thoughts?

We disagree for once, mark this day!


More information about the Standards mailing list