[jdev] Python/XMPP GSoC proposal

Sylvain Hellegouarch sh at defuze.org
Wed Mar 26 08:40:29 CDT 2008

>>  That being said, a XMPP server is really meaningless if you don't
>> define
>>  how much of XMPP you'd like to support. For a student project, I guess
>>  XMPP-core, XMPP-IM [3] server side would already be a solid project.
>> More
>>  might hurt the success of the project.
> Instead of creating (yet another) full XMPP server, how about creating
> something like a standalone MUC component. This requires implementing
> a part of an XMPP server, but certainly not everything from core and
> IM. I have had a situation where I would have really liked to set up a
> MUC conference server without running the full blown server.
> Or maybe, to have something more general, something that can take any
> component (like a transport, ...), and serve it standalone. I haven't
> given this much thought whether this technically makes sense or  is
> possible at all, but from a user's perspective I think it would (cfr
> the MUC case).
I can certainly see where you coming from but you may not be able to do
just that without implementing most of RFC 3920 and part of 3921. That
being said, if your application reisde in a closed environment you could
consider dropping part of what would be useless to you. That wouldn't work
well if you were to open your XMPP network to external nodes which may
require more of it.

Or you could just use ejabberd :)

- Sylvain

More information about the JDev mailing list