[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
addressable.

> 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!

Matthew



More information about the Standards mailing list