[jdev] Re: Re: The State of Our Code-bases

[Jacek Konieczny]

On Thu, Sep 02, 2004 at 09:35:32PM +1000, Trejkaz Xaoza wrote:
> The competitors in the space I was really talking about are Ejabberd and 
> Jabberd.  Ejabberd is probably far better on the usability side... I wouldn't 
> know, as it still can't do virtual hosting, which would be the top priority 
> feature if it were to take the place of Jabberd on a server which uses this 
> feature.

I guess it is possible to start multiple ejabberd instances on one
machine. Different ports, of course, but this is not problem as SRV
record should be used to find the right port. So the
virtual-hosts-problem is solveable.

>     But install it from a distro's packages, and the configuration _there_ 
> will work out of the box.  There is your ease of use for Apache.

It doesn't work out of the box. In the best case (or maybe the worst)
out of the box it serves unusable page. Minimum-competent
administrator/webmaster is needed to make it a real web server.

> Now Jabberd.
>     Starting with a blank configuration, hard as always.
>     Starting with the sample config, you have to replace a few strings, 
> basically the same as Apache... the server name, admin names, and a couple of 
> other things.
>     But again, install it from a competent distro's packages, and the 
> configuration is supposed to work out of the box.

If the instalation process is not supposed to be interactive, nothing
more than "localhost" server without s2s connection may work out of the
box. This way jabberd 1.4.x, jabberd 2.x and ejabberd packages work (or
at least are supposed to work) in PLD Linux Distribution. Usually global
substitution of "localhost" to the right domain and setting up DNS is
all what is needed to make it work as world-visible Jabber server. But
of course minimum-competent administrator is needed.

I hope no "competent distro" will release package which works out of the
box on hosts FQDN (usually that is not what admin wants) with full S2S
connectivity and open in-band registration. That would be bad --
thousends of open Jabber servers ready for spammers to use. Those
servers setup now could be used even after several years and never
fixed.

> That there is still so much criticism directed at Jabberd for its difficulty 
> to get working, reflects not only on Jabberd itself, but on the people who 
> created packages for their distros, which were supposed to work out of the 
> box.

Which jabberd do you mean. Jabberd 1.4.x is not XMPP compliant and XMPP
is supposed to be the current Jabber protocol. Jabberd 2.0 is buggy --
unstable and probably insecure (most crashes are because of buffer
overflows and similar problems). It is not ready for proffesional use.

> So why don't we direct the attention _there_?  If all Jabber packages on all 
> distros worked out of the box, would there still be a good excuse not to run 
> it?

Even good packaging of buggy software doesn't solve anything. It can
even make things worse (people will know that Jabber is thet buggy
service in distributions).

Greets,
	Jacek