[jdev] Python/XMPP GSoC proposal

Fabio Forno fabio.forno at gmail.com
Wed Mar 26 15:22:16 CDT 2008


On Wed, Mar 26, 2008 at 2:20 PM, Remko Tronçon <remko at el-tramo.be> wrote:

>  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).

Another possibility is doing an extended component protocol capable of:
- filtering any type of message and eventually modify it
- creating and manipulating suer data
- creating and manipulating user sessions

There are two ways for doing it: a new component protocol or some API
for a server. AFAIK ejabberd already has something similar but you
must use erlang ports. Also Openfire, with plugins allows it, but you
must extend the server in the same addressing space with java. A new
component protocol with implementation would be too much for a GSoC
project, but some "network" API available via xml-rpc, soap or some
optimized protocol, it doesn't matter, would fit and very useful. In
this way you could let the server do what it does better, routing
messages, and use your favourite language for controlling its
behavior.
Now it's up to server developers to say whether this makes sense or
not. As user I'd like it a lot.

Bye
-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com



More information about the JDev mailing list