> > Today, I'm wondering whether a simple, specialized process to which
> > the main client forwards Jingle-related XMPP stanzas to, using a local
> > TCP connection, is the easiest/most portable way to do it.
> > Essentially like jinglepipe but over a socket.
>
> Certainly most portable (modulo how the client and the component find
> eachother).
I guess, since the client would be starting the sub-process, it could
invoke it with something like "jinglebot --port 1234". Or the other
way around, the sub-process would search for a free port, bind it and
tell it to the client via stdout (like CORBA-based apps do with the
IOR).
> I have been trying to avoid having an XML parser in my C
> code, since C plus XML doesn't sound very fun.
+1
Every time I think of external XMPP processes/processors, I end up
thinking of embedding Lua or TinyScheme to handle XML. Unfortunately
as far as I know neither has an XMPP library. I'm not sure that would
be needed for Jingle, though (or at least for libjingle, see below).
On another note, that is how a local transport based on something like
bitlbee or libpurple might look like. Bitlbee even works like that
already -- too bad it disguises itself as an IRC server instead of an
XMPP server, or we'd already have a multi-network cross-platform
cross-client local transports. :-)
> On the other hand, extending XEP-0114 (Jabber Component Protocol) to
> cover client plugins might be interesting ☺
Hmm, wouldn't that be a bit overkill (albeit cool)? Usually you have:
on('http://some-jabber-namespace', handler);
Here, "handler" would be transparently delegating the packet over the
socket and the rest of the client wouldn't have a clue.
(I'm sure there are a hundred gotchas here in the general case, I'm
just thinking about libjingle right now.)
Massimiliano
--
Massimiliano Mirra
http://sameplace.cc
http://hyperstruct.net
