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
