libpurple Jabber Transport

[Ethan Blanton]

Jeremy Bowers spake unto us the following wisdom:
> 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

[snip]

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

As you may be aware, open source projects are generally driven by
individuals who contribute out of their free time, not funded
organizations.  (There are a few, high-profile, notable exceptions to
this.) Pidgin is such a project.  As such, we cannot "support"
projects which use libpurple in the manner which you seem to be asking
for.  That said, as far as the goals of a project which uses libpurple
or Pidgin coincide with ours and our developers have time, we are
certainly willing to work with you; see the Adium project, Gabriel
Schulhof's work to bring Pidgin to ITOS, or Will Thompson's work on
telepathy haze.  Note that in ALL of these examples, there is at least
one active developer on the *other* project who is active with
libpurple/Pidgin development, feeding us changes and working closely
with us to help us help their project achieve their goals.

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

We, of course, will answer your questions to the best of our ability,
as we would any other user of libpurple.

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

This is not currently possible in the way that you want, if I
understand your desire.  libpurple is not a module which can be loaded
within perl; rather, the perl plugin loader is a module loaded within
a libpurple client.  This means that you cannot simply 'use Purple;'
in a perl script somewhere and start chatting over IM.  You would have
to write a libpurple client (in C, currently) which framed your perl
interaction, the way things currently stand.

In other words, we don't exactly have perl bindings for libpurple.
What we have is a perl plugin interface.  It is not impossible to
*write* perl bindings, but no one has done so, and it is a nontrivial
amount of effort.

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

This does not exist because it is not currently possible.

> * 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?

There are dozens of implementors of Yet Another Meebo on this list; it
seems to me that some of them have indicated a degree of success in
this venture, but I don't think the core libpurple developers can say
for sure.  Certainly the library was not designed with this in mind.

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

We are most interested (someone feel free to correct me if I am wrong)
in the changes you have to make to libpurple to make this happen,
assuming that they are clean and coherent.  We have historically
avoided maintaining other people's projects in our repository, because
invariably those "other people" disappear at some point, leaving us
holding the bag -- if we don't have a vested interest, at that point
the donated code bit rots.

I'm not sure any of this really answered your question; the bottom
line is, we're willing to work with you as far as you're willing to
work with us, and time allows.  Some projects have found this to be a
rewarding relationship structure, some have not.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080108/0f1d9c49/attachment.sig>