<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12"> <TITLE>Implementing Jabber Server in other Languages (Was RE: [JDEV] Customizing Jabber server)</TITLE> </HEAD> <BODY> > 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@vedalabs.com </BODY> </HTML>