On Wed, Mar 26, 2008 at 2:20 PM, Remko Tronçon <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
