GSOC idea : file transfer plugin

Jean-Grégoire Foulon at
Tue Mar 25 09:39:57 EDT 2008

On Mon, Mar 24, 2008 at 11:13 PM, Etan Reisner <pidgin at>

> On Mon, Mar 24, 2008 at 06:57:27PM -0400, Evan Schoenberg wrote:
> >
> > On Mar 24, 2008, at 6:52 PM, Roberto Barboza Jr wrote:
> >
> > > I would like to know if i could develop this idea as my GSoC project.
> > > It seems well explained to me (i couldn't explain better or add
> > > anything to the idea right now), so if it's ok, i'll read the dev wiki
> > > to start planning how this could be done.
> >
> > I don't think the 'file transfer plugin' (basically an FTP server
> > implemented as a Pidgin plugin) is within appropriate scope of the
> > project.  There are plenty of existing solutions to file sharing,
> > including solutions provided by the protocols themselves.  Do any
> > other developers disagree and think this would be a project for which,
> > as described in Jean-Grégoire Foulon's email, they would vote when it
> > comes time to accept or reject proposals?
> >
> > -Evan
> I agree completely, implementing an entire ftp/http server inside pidgin
> is not at all something I think appropriate for pidgin nor do I
> particularly think it is something complex enough to be a valid SoC
> project (especially given the fact that Sean's book _Open Source Messaging
> Application Development: Building and Extending Gaim_ has a *very*, *very*
> simple webserver in a plugin as one of the code examples for Chapter 7).
> Extending the webserver plugin from the book to handle accepting a "path"
> and serving different known files based off of that path should not take
> much time, assuming you don't intend to make it a full-fledged http server
> or anything.
> I also happen to think there really aren't that many people for whom such
> a plugin would truly be useful, and I would much rather see more broadly
> useful projects undertaken as part of the Summer of Code.
> If this project idea is in fact not even to create a plugin to actually do
> anything but rather to create a plugin to manage transacting the transfer
> type information, the location and port information, and the
> login/credential information to an existing ftp/http/scp service (which
> increases the complexity of the deployment of this plugin considerably)
> then I think this is even less of a meaningful project since a person
> could do all of this without the plugin just fine. (I'm assuming the
> plugin wouldn't set up the ftp/http/scp service for the user as that would
> quite likely be rather impractical if not downright impossible.)
>    -Etan
> _______________________________________________
> Devel mailing list
> Devel at
As I don't use the original client and mainly use Pidgin,, I am not aware of
the other file sharing features offered by the different protocols,  but I
don't think that it is very common to offer the ability to browse a
contact's directory and start a client to client transfer.
I don't know how many people will use it if it works, but I think that
sending a 30 mb video or PDF to his friends is still somethin hard to
accomplish for people who don't want to set up a FTP server by themselves.
The more of your contacts use it, the more you are likely to use it, it is
quite viral. If none of your contact use it, you won't install it.
Concerning the complexity of the subject, I am usually optimistic regarding
the time of completion of projects and I don't think this project is too
short if we consider it is supposed to work out of the box.
-designing everything
-choosing the components to use (openSSL, GNU TLS, etc.)
-testing on Windows, UNIX and maybe OS X
-taking care of the server and client side of the plugin
-implementing uPnP
-handling certificates: the plugin must help creating a certificate if the
user hasn't any.
-integrating everything in a pidgin plugin
-lot of things I forgot

I agree that having a server that runs as a pidgin plugin might not be the
most elegant solution, but the goal would be to have something that is
really easy to setup on every platform.

The other solution I could imagine would be to create a "protocol plugin"
where every user will just be a dynamic DNS entry and a port with either a
scan or a IP address test (e.g. ip != to know if they are online.
But I think it would make less sense since we would have to create new
contacts, different from the contacts in the contact list. There wouldn't be
any chat possible with those users, so there wouldn't be much logic in
having this software as a gimp plugin. And a server would still be running
inside a plugin...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Devel mailing list