Quantcast

libpurple Jabber Transport

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

libpurple Jabber Transport

Jeremy Bowers-3
libpurple Jabber Transport

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.


_______________________________________________
Devel mailing list
[hidden email]
http://pidgin.im/cgi-bin/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: libpurple Jabber Transport

Ethan Blanton-3
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

_______________________________________________
Devel mailing list
[hidden email]
http://pidgin.im/cgi-bin/mailman/listinfo/devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: libpurple Jabber Transport

Jeremy Bowers-3
RE: libpurple Jabber Transport

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

That's all I meant by "support"; there's no clean English word for the standard open source (non-)relationship. I may be supported by a company, but I personally understand how open source works. Your message answered my questions as well as I could have wanted; thank you.


_______________________________________________
Devel mailing list
[hidden email]
http://pidgin.im/cgi-bin/mailman/listinfo/devel
Loading...