Implementing Jabber Server in other Languages (Was RE: [JDEV] Cus tomizing Jabber server)

Matt Diez matt at vedalabs.com
Wed May 9 12:03:42 CDT 2001


> I've been wondering why the Jabber Server hasn't been implemented in other
languages such as Java or Python with
> C calls to the appropriate libs. It seems that multiple server platform
implementations could only help in the 
> adoption of Jabber.


This is something I've been thinking about for a
while, and would like to open up to some discussion.
 
I really don't see implementation of Jabber in other
languages as being that practical or necessary. I
must confess, I really don't like changing server code
to change server behavior (registration, I'm looking 
at you). But, I really can't see how/when/where/why
a server in, say Python is all that advantageous,
save for its multiplatform capabilities. But, I must
say, given the speed Jabber must work to route messages,
I don't see a Python (or any other language of your choice)
server as 
a) useful
b) practical

This demands the inside-out reworking of the Jabber server
in a variety of languages, and the development of alternate
servers that can "anticipate" future changes to Jabber 
internal protocols and such.

Now - the ability to change certain server behaviors does
make itself attractive, and is a pretty compelling argument
for implementing Jabber in other languages, but I'm not 
sure there aren't simply better ways around this, particularly 
ones that don't require wholesale server rewrite whenever
fundamental changes in the default Jabber server occur.

I think the focus of current server developers should be
to first document all internal protocols - (s2s and xdb
being fine examples), and then to worry about making
Jabber as portable as possible. I've got a pretty hefty
RS6K sitting next to my desk begging to run Jabber, but
even IBM's porting efforts have only been partially 
successful. 

Which, in many ways - is a pretty strong argument for
much more platform-agnostic languages (perl, python,
java), but I think we need to look at Apache as a good
model. 

Yes, I know that Apache is only a server (well not so
much these days) and Jabber is a set of related technologies, but 
I feel that making the current Jabber server as fast/friendly/portable 
as possible is the real key here, and maintaining a variety of
separate server implementations would be...


On second thought - David Waite's right - we have to look at separating
protocol
from server implementation.

You know - I just contradicted myself. 

Matthew D. Diez
matt at vedalabs.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20010509/ab050437/attachment-0002.htm>


More information about the JDev mailing list