It seems like the prototyping point here is the strongest. From a perf perspective, C/C++ all the way seems pretty important for carriers and large ISPs (like us if I may be so bold), but not for people tooling around with new features... If we all agree with this, the nice thing might be that a second/alternate language version would have an EXPLICIT goal of being readable and modifiable and NOT being efficient or cheaply/quickly scalable. Of course, we'd never agree on the language, so there'd end up being 10. -----Original Message----- From: John Hebert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 3:43 PM To: [EMAIL PROTECTED] Subject: Re: Implementing Jabber Server in other Languages (Was RE: [JDEV] Cus tomizing Jabber server) 5/9/01 8:03:42 AM, Matt Diez <[EMAIL PROTECTED]> wrote: > 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, Quicker to prototype and test new capabilities, for one. Lots of XML libs/tools for another. Python works best as a glue scripting language between components. > save for its multiplatform capabilities. But, I must > say, given the speed Jabber must work to route messages, That's why I mentioned calling C binaries from Python or language X if needed. Also, performance may not be a priority. I can imagine using the jabber server for other tasks besides IM chatting. > I don't see a Python (or any other language of your choice) > server as > > a) useful > b) practical Oh yeah? Moldy bread. > 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. Interesting. Kinda like Apache httpd's DSO modules. > 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'm getting confused... didn't you just say something to the contrary before this? And don't you mean "protocol" instead of your last use of "server" in the above paragraph? If so, agreed, server rewrites for protocol changes is icky. > 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. Yup, you are correct. St. Peter mentioned that this work is being done. Bring out the cat o' nine tails. > 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. Are you skipping on your Lithium again? > 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... Jabber = related technologies? That's not what I thought Jer had in mind. > 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? > You know - I just contradicted myself. I'm getting used to it. -- John Hebert System Engineer http://www.vedalabs.com Changing your state of mind through sound. _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
