[Standards] Components

Dave Cridland dave at cridland.net
Thu Feb 18 11:33:59 UTC 2010


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.

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.

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.

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.

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.

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.

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

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

Any thoughts?

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list