Re: [JDEV] Re: Implementing Jabber Server in other Languages (Was RE:[JDEV]Customizing Jabber server)
Nitin Borwankar wrote: John Hebert wrote: Hi John, OK, I'll be moving to the protocol list after this. Actually on second thoughts I don't think that'll be very productive. I looked. That list doesn't seem to be very active. I could have sworn I could hear my email message echo as it bounced around inside the cavernous empty spaces there. And my SMTP server went HELO and the one on the other side said ..ELO..LO..O :-) As for the python-dev list the last message posted there appears to be mine !! from Mar 2000 asking if the Python-Jabber project is still active ? No reply, no more messages. Not even an echo. Man this stuff is spooky ! So is there really a place where protocol doc issues are being discussed ? Python server implementation issues ? ...ssues ? ... ues ? ... Nitin Borwankar. I didn't know there was a separate list for the protocol discussion, must have missed some messages in between. As far as what messages the server should handle, we should step back and talk in terms of what functionality is considered core Jabber functionality and what is not. The latter consists of issues related to pthreads, etherx ... ie implementation dependent and also those related to transports for other IM protocols. To me the core functionality in order of importance is that which allows 1) messaging (messages and file transfer) a) 1-1 b) group 2) presence subscription/notification 3) user directory/roster/buddy lists So IMHO, we should include those protocol enable that enable these functions, in the core compliance suite. I haven't been up to speed with all the changes happening since server v 1.1 but AFAIK these have been implementation/architecture improvements rather than fundamental protocol changes. So if I have missed or misstated something please jump in and correct I'd be glad to provide effort and input to the actual protocol documentation effort. OK, over to the protocol list now. Nitin Nitin, All of your ideas are good and worth pursuing further. A co-worker of mine, Dustin Puryear, is building the test suite. I'll speak to him about a compliance test, but first I'd like to clarify some of the ideas you mentioned. Specifically, what messages should the server handle correctly to constitute compliance? Should this be a subset of the current protocol or the entire set? I'd also like to find out more about the python based jabber server project status. In hibernation? I'd really like to help with this. I was thinking however, out of consideration to jdev, that we should move these threads to the protocol and python-dev mailing lists. I've cc:ed those lists. What do you think? To everyone following these threads, consider this an open invitation. Thanks, John Hebert -Original Message- From: Nitin Borwankar To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: 5/12/01 4:26 PM Subject: Re: Implementing Jabber Server in other Languages (Was RE: [JDEV] Cus tomizing Jabber server) 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
[JDEV] Re: Implementing Jabber Server in other Languages (Was RE:[JDEV]Customizing Jabber server)
John Hebert wrote: Hi John, OK, I'll be moving to the protocol list after this. I didn't know there was a separate list for the protocol discussion, must have missed some messages in between. As far as what messages the server should handle, we should step back and talk in terms of what functionality is considered core Jabber functionality and what is not. The latter consists of issues related to pthreads, etherx ... ie implementation dependent and also those related to transports for other IM protocols. To me the core functionality in order of importance is that which allows 1) messaging (messages and file transfer) a) 1-1 b) group 2) presence subscription/notification 3) user directory/roster/buddy lists So IMHO, we should include those protocol enable that enable these functions, in the core compliance suite. I haven't been up to speed with all the changes happening since server v 1.1 but AFAIK these have been implementation/architecture improvements rather than fundamental protocol changes. So if I have missed or misstated something please jump in and correct I'd be glad to provide effort and input to the actual protocol documentation effort. OK, over to the protocol list now. Nitin Nitin, All of your ideas are good and worth pursuing further. A co-worker of mine, Dustin Puryear, is building the test suite. I'll speak to him about a compliance test, but first I'd like to clarify some of the ideas you mentioned. Specifically, what messages should the server handle correctly to constitute compliance? Should this be a subset of the current protocol or the entire set? I'd also like to find out more about the python based jabber server project status. In hibernation? I'd really like to help with this. I was thinking however, out of consideration to jdev, that we should move these threads to the protocol and python-dev mailing lists. I've cc:ed those lists. What do you think? To everyone following these threads, consider this an open invitation. Thanks, John Hebert -Original Message- From: Nitin Borwankar To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: 5/12/01 4:26 PM Subject: Re: Implementing Jabber Server in other Languages (Was RE: [JDEV] Cus tomizing Jabber server) 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
Implementing Jabber Server in other Languages (Was RE: [JDEV] Customizing Jabber server)
Title: Implementing Jabber Server in other Languages (Was RE: [JDEV] Customizing Jabber server) 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 [EMAIL PROTECTED]
