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

Peter Saint-Andre stpeter at jabber.org
Sat May 12 17:42:37 CDT 2001


Hi Nitin,

Thanks for stating the point so forcefully (and for mentioning Jabber to 
France Telecom so long ago :). I think there is general agreement in the 
Jabber community that we need to document the entire protocol (not just 
client to server) so that other server implementations can be written. 
Now we just need to do it! :)

Peter

Nitin Borwankar wrote:

> Hi Iain, all,
> 
> I have been lurking on this list but had brought up this issue on IRC channels, of defining the protocol separately and building another *interoperable* and *independednt* implementation so as to meet IETF standards.  This was last year back when the Jabber protocol was being prepared for submission to the IETF as an IM standard.
> 
> This issue, that the server implementation is the protocol definition, is a real problem for the future expansion of Jabber.
> All successful widely deployed open protocols have had these two efforts separated.
> A tremendous amount of effort has gone into the creation of all kinds of clients for Jabber but there is only one server.
> The fact that the source code is available makes it an Open Source development project, but not an open protocol development effort.  I too have little interest in the C implementation.  I have more interest in the Java and Python server implementations.
> 
> I had begun a Python-based server development effort last year but it was very prematurely truncated for personal emergencies that caused me to put all non-billable work aside for a long time.  I was consulting for France Telecom in Brisbane Ca and was instrumental in giving very positive reviews of Jabber to my boss after attending the first developer bootcamp in Denver last August.  These were probably ultimately forwarded to the people in France, re-inforcing their opinions.  Interesting to see that France Telecom has now invested in Jabber.  Great stuff!!
> 
> I have also noticed in passing that there is a test suite being developed.  If the test suite could be evolved into a protocol compliance suite, that would be the best way to leverage existing efforts.  Then, any new server development effort could at least meet some baseline interoperability by passing the test/compliance suite.  In time this will get documented and evolve in to the protocol definition doc.
> 
> I would strongly urge Michael Bauer, and others to raise this issue at the business level - it will accelerate Jabber adoption exponentially.  Jabber Inc. need not worry about the business implications - the SMTP protocol is widely documented and publicised, and there are a number of competitiors, but Sendmail Inc. still has a largest market share by far in the Enterprise email server space.  So it will be of Jabber Inc. not to worry.  And there will also be many simple implementations of the protocol adapted for different business use by different user constituencies.  These will only create greater demand for the commercial version.  I don't want the source for the commercial version but I do want the protocol effort to be separated and opened up,
> and have wanted it for almost a year now.
> 
> So please make this a priority, its a win-win-win all around.
> 
> Nitin 
> 
> Nitin Borwankar
> President and CEO, Borwankar Research Inc.
> ntin at borwankar.com
> 510-653-8394
> nbor on IRC
> 
> At 06:50 AM 5/11/01, Iain Shigeoka wrote:
> 
>>At 02:42 PM 5/9/2001 -0500, John Hebert wrote:
>>
>>
>>>>  On second thought - David Waite's right - we have to look at separating
>>>>  protocol from server implementation.
>>>>
>>>My point all along. Apache has the W3C. What does Jabber have? Do we
>>>need a separate jabber protocol effort separate from the server devel effort?
>>>
>>Yes.  We need to separate protocol from implementation.  Most people I've spoken to are at least philosophically in agreement on this issue.  This has been a problem since Jabber has evolved as an implementation that defined the protocol.  IMHO the time has really come to split the protocol off.  Jabber has remained coherent until now because there has only been one server implementation available so the implementation has defined the protocol.  However, as Jabber.com now as a separate server (albiet very closely related) and there are other efforts to develop servers, a separate protocol standard is going to become essential.  As I understand it, this is something that we can use the Jabber Foundation as a tool to help us accomplish.
>>
>>FYI, I'm very interested in the protocol and implementing my own Jabber server (in Java not Python) and have little/no interest in the current C implementation.  Reading the protocol docs from this perspective has really been what's gotten me interested in better defining the protocols to stand alone from the implementation.  As it stands now, it is pretty much impossible to write a server based on the existing protocols because they are incomplete.  In addition, there is no way to test your protocol compliance except in relationship to the current C implementation.  I'm hoping to also work on addressing that issue as well (standard compliance when a standard exists).
>>
>>-iain
>>
>>
>>_________________________________________________________
>>Do You Yahoo!?
>>Get your free @yahoo.com address at http://mail.yahoo.com
>>
>>_______________________________________________
>>jdev mailing list
>>jdev at jabber.org
>>http://mailman.jabber.org/listinfo/jdev
>>
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 
> .
> 
> 






More information about the JDev mailing list