[ejabberd] Re: ejabberd_service
mange at freemail.hu
Sat Jun 10 01:25:52 MSD 2006
s.devrieze at pandora.be writes:
> AFAIR, the method that jabberd2 is no official JEP. So, I guess it
> is very unlikily if support for this will be included in the main
> branch until that protocol is converted to an official JEP. Maybe
> someone can point this out on standards-jig?
Nor is the ejabberd method an official JEP. JEP-0114 doesn't specify
how connections from a component to a server are to be made (which
port, which component JID, whether all components can use the same
port, etc), so those things are up to the implementation. ejabberd
implements one behaviour, and jabberd2 implements another;
compatibility between server implementations traditionally hasn't been
a goal of the standards JIG.
On to the topic; I'll compare the two methods.
+ You know in advance which JIDs the components can claim.
+ You can configure a separate password for each component.
+ You can do load balancing by connecting several component instances
to the same port (useful for JUDs, not for transports and other
components requiring sessions)
+/- The component can use several JIDs at once (but JEP-0114 doesn't
specify how to do that)
- ejabberd doesn't check the JID claimed in the stream header.
- You can't connect several components to a single port.
- You have to specify component JIDs in two places - ejabberd
configuration and component configuration.
The opposite of the above.
It seems to me that the best solution would be to keep the existing
behaviour, but add two new features:
- If the "hosts" configuration directive has the value "any", use the
jabberd2 method instead.
- If it doesn't, reject connections trying to bind a non-permitted
JID, to ease debugging of component configurations.
JID: legoscia at jabber.cd.chalmers.se
More information about the ejabberd