libpurple Jabber Transport

[Jeremy Bowers]

My name is Jeremy Bowers, and I am the team engineering lead for the Barracuda IM Firewall: 

http://www.barracudanetworks.com/ns/products/im_overview.php

We have been providing the Python transports for our users, but they are not meeting our needs. I don't want to be too specifically critical of another project, but I can highlight the fact that each transport is an entirely separate code base is one of the major problems.

I have been looking at options, and it seems building a transport out of libpurple seems like a good choice. I am posting this message to see how much support I might be able to get for this project.

I am perfectly happy to do all the XMPP interaction work, but I could use some help navigating the libpurple code base, and the ability to ask questions of somebody. 

I do have two initial questions:

* I really, really, really want to write the transport in Perl, not C, for many reasons. The perl bindings seem to be almost, but not quite, complete. How much work will it be to complete the Perl bindings to the point that you can write a complete IM client it? (Would it be easier for whoever made those bindings in the first place to finish them?) 

If somebody wanted to be *really* ambitious, I could use a minimal perl script to connect to a service, any service, with libperl; as hard-coded and as easy-to-write as you like. That would get me over the initial hump and might be much easier for someone intimately familiar with the library, rather than someone just starting like me. (I am not "asking" for this or expecting it, just saying it would be very helpful, probably for others too.)

* How hard is it going to be to have many distinct people logged in with libpurple in the same process? It looks to me like it should be mostly feasible as the library currently is, but I could use an expert opinion. If not, how hard would it be to fix it to work as a transport should?

This transport will of course be released as GPL2, as the license requires. We can work out any other interesting administrative details later (such as where it eventually ends up; I have no problem with this ending up in your main repository, if you want it that way, nor do I have a problem with our maintaining it elsewhere, and of course we'll probably start with separate repositories). We're not starting this for a few weeks, I'm sending this to test the waters and give us a chance to discuss it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080108/5ff6e5e3/attachment.html>