[Standards] Re: Simple Jingle example(s) and spec(s) wanted

Robin Redeker elmex at x-paste.de
Wed Feb 7 14:01:50 UTC 2007


I'm a client library developer, I'm currently writing a Perl module
for XMPP.

On Wed, Feb 07, 2007 at 02:15:12PM +0100, Alexander Gnauck wrote:
> Peter Saint-Andre wrote:
> >..... I wish it were, but
> >working protocols, instead of half-working extensions that lead to a 
> >poor user experience (as I think we have right now with file transfer).
> i agree with Peter and all other posts in this thread.
> I also agree that Jingle could be the way to go. But as Remko said it's 
> damn complicated. Most of us are busy with writing server, client or 
> library code and implementing other existing XEP's. Getting into ICE, 
> STUN, TURN and all the other stuff is another full time job. I assume 
> most of the current projects don't have this resources. And it will be 
> exactly the same with E2E.

This is exactly what I thought when flying over the Jingle stuff.
I've been skimming through Jingle and the attached protocols: ICE, STUN
and TURN. And I decided I won't implement it so soon, because it looks
like the hell of a lot of work (more than I can handle).
And I'm alone on my project. Implementing XMPP RFC3920 and RFC3921 along
with some XEPs is possible for me. But at least for the Perl world
it looks quite dim when it comes to ICE, STUN and TURN.
Maybe there are C libs I haven't heard of yet for all this, if there
were, then I could just make bindings to them which would be a reasonable
amount of work.

But I indeed don't feel capable of implementing ICE+STUN+TURN all of my own.
Especially when there are no implementations to test against yet.

> What we need here is a library which could be used like a black box from 
> all programming languages. As Peter said the XSF has some money and is 
> willing to sponser such projects.

I've been taking a look at libjingle. It's a nice piece of code. It seems to
implement everything a client developer needs: XML parser, XMPP, TLS, ... whatever.
But it doesn't seem to be very pluggable (or at least I don't see a way
in the API), so it's unusable for me.
And I also see no other ways than using threads to use libjingle in an
interactive process (but libjingle still seems to want it's own XML stream).

Libraries have to be pluggable for client developers and not assume
any kind of event loop. Or even doing all the (XMPP) communication
themselves like libjingle seems to do.
All client developers need is some assistance to deal with the
protocols, they already know how to send and receive data from sockets.

These are just my two cents :-)


More information about the Standards mailing list