melo at simplicidade.org
Thu Feb 18 12:48:09 UTC 2010
On Thu, Feb 18, 2010 at 11:33 AM, Dave Cridland <dave at cridland.net> wrote:
> 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.
Components should authenticate themselves and have an identity apart
of the domains they serve, yes. As a regular JID? I don't see any
clear advantages on that, even reading your other arguments below.
> 2) Components can request domains.
> 3) Components can request domains *with options*.
Same answer as Matthew Wild gave you.
> 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
Components become another user connected to the server, yes. And
having their identity separated from the domains they service is a
plus, but after that I don't really understand what "expose a common
component interface" means.
> 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.
No need. Users subscribe to the component JID and receive the
<presence> stanzas for each resource (component connection). Only
trusted users will be accepted.
You can reuse the usual roster/subscription model here, no need to
create another protocol.
> 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.
Different things should be different. XEP-225 brought the usual C2S
stream semantics to components, so you can already use most of the
usual frameworks for both C2S, 225 and even S2S.
Unless you mean that components would reuse the public C2S (or even
S2S as Matthew suggests) ports as the component port. That is even
worse. They are different things, and require different policies.
Usually you want tight bandwidth limitations on C2S connections, and
you want a lot of filtering, white/black-lists and DoS prevention
stuff in S2S connections. If you start putting Components on those
ports, you have to disable some or part of those defense mechanisms.
Also, for your firewall administrator, you have to explain why a
public port is also being used by internal trusted components and why
he has to apply different rules to detect network abuse.
Besides all that: what problem are you trying to solve? At my previous
employer, where we abused component connections (up to 70 component
connections at some points in time, over several domains) it was never
a problem to manage those ports.
> b) Components now open a single connection, reducing complexity, and can
> instruct the server on the correct configuration, reducing administrative
Why would a component open more than one connection? I never used a
component that did that. Can you give us an example of a component
that requires multiple connections and why?
I'm assuming that you are not talking about multiple component
instances. For those I want/need multiple connections because those
instances are running on several servers.
> c) We have a framework to build common management of components of all
> kinds, without risk of interfering with the interfaces actually exposed.
Add component auth, allow them to have rosters and presence
subscription, and you already have all that you need.
Separating component identity from the domain serviced is the main idea.
xmpp:melo at simplicidade.org
mailto:melo at simplicidade.org
More information about the Standards