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
[email protected], 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:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
