Peter Saint-Andre wrote:
Mridul Muralidharan wrote:
XMPP Extensions Editor wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Component Connections
Abstract: This document specifies a standards-track XMPP protocol
extension that enables server components to connect to XMPP servers.
URL: http://www.xmpp.org/extensions/inbox/component.html
The XMPP Council will decide at its next meeting whether to accept
this proposal as an official XEP.
What exactly does binding a hostname mean ? Multiple component JID's
over the same stream ? If yes, why exactly do we need it ?
Think virtual hosts:
conference.jabber.org
conference.xmpp.org
Hmm, this is very tricky ground - and I am not sure if the proposal is
considering a lot of aspects of hosted domains ...
For example, how does conference.jabber.org get associated with
jabber.org virtual domain (so that users of jabber.org will be
implicitly exposed to only this muc, not to conference.xmpp.org, etc).
I can understand the intention here - the way we handle this is slightly
differently: the muc/pubsub/jud is part of the server, so the
server/component 'knows' which hosted domain the client belongs to, and
which hosted domain the conference should belong to, etc.
With an external component, this becomes really tricky without wildcard
support of some sort - something like conference.<hosted_domains>, etc.
Thinking more, to expose this sort of behavior, we will need a way for
components to query for list of hosted domains (which would not be
available in a lot of cases - it is typically lazily loaded (and subject
to change at runtime), sometimes to the tune of 4k+ domains).
Typically, in our deployments, external components are not restricted to
a domain - but are available to the whole deployment. We would expect
impl specific acl's controlling which component is exposed to which
hosted domain.
Etc.
Also, since there seems to be no restriction on what can be bound, it
can potentially bind valid s2s domains ... unlike the current component
jid which is preconfigured at the server.
Yes that needs to be specified more carefully.
Also, how would this interact with dix [1] ? Not sure of the state of
that submission - but just the support for multiple resources made it
very useful proposal.
Ask Chris Mullins. :)
Asked JD :)
Thanks,
Mridul
/psa
