[ejabberd] More virt host woes.

Brian Cully bcully at gmail.com
Thu Feb 7 20:53:26 MSK 2008

On 6-Feb-2008, at 19:45, Badlop wrote:
> It would be nice to improve the documentation for developers.  
> Existing material:
> * The ejabberd Developers Guide documents the core
> http://svn.process-one.net/ejabberd/trunk/doc/dev.html
> * ejabberd module development
> http://www.process-one.net/en/wiki/ejabberd_module_development/
> * And a mixed bag:
> http://www.ejabberd.im/development

	I've gone through this stuff already, and it's incredibly anemic. It  
taught me almost nothing that a cursory reading of the source didn't  
teach me. The problem is  not understanding the overall architecture,  
the problem is reimplementing parts of that architecture without  
disturbing too much. That requires much more in-depth documentation.

> Regarding the comments in source code: I agree, sometimes a comment is
> really required to understand the code.
> In other cases [1] it's preferable to not comment. Do you agree? :)

	I certainly believe code should be self-documenting as much as  
possible, and over-documentation can be a real problem. I don't need  
comments on a lot of the code in ejabberd, as its fairly  
straightforward. However, that's not a black and white thing, and  
ejabberd has such a dearth and in so many important places that it's  
extremely frustrating.

> If you finally can modify ejabberd for your requirements and use it,
> do you plan to contribute to it somehow, for example documenting the
> functions that you had to investigate during your development stage?

	I actually hope to produce patches that can be accepted into  
mainline. I'm absolutely willing to share. My job is not supposed to  
be xmpp server development, my job is supposed to be writing apps on  
top of xmpp. The more server stuff I can foist off on the world at  
large the better. But I absolutely must work ejabberd into an  
acceptable state for my uses, regardless of community support.

> After trying Magnus' patch, and digging in the code to check what was
> going on, I concluded that the feature would require many invasive
> changes in the ejabberd core.

	Magnus' patch is a slightly more verbose version of what I had  
written, and is thus a total hack. Restarting ejabberd at midnight, or  
ever, is a non-starter. We're looking for carrier-grade solutions here.

> Any explanation as to why you need this feature so much?

	XMPP hosting will require supporting many thousands of domains. My  
company already hosts thousands of domains, and we want to supply XMPP  
hosting for them. We are also trying hard to be truly carrier-grade,  
and that has a lot of constraints on how we accomplish this task.


More information about the ejabberd mailing list