Fwd: GSoC idea - Plugin repository on pidgin.im

[Ibrahim Awwal]

On Sat, Mar 28, 2009 at 9:58 PM, Gary Kramlich <grim at reaperworld.com> wrote:
> Ibrahim Awwal wrote:
>
> <snip>
>
>> With regard to native plugins, I actually hadn't even thought of that.
>> I assumed that all plugins would be open source, but now I realize
>> that even with open source you can't guarantee that the source
>> corresponds to the binary without compiling it yourself, and I'm
>> pretty sure it would be impossible to set up a pidgin build
>> environment on Google App Engine. I also had a thought after writing
>> that previous email; it should be a libpurple plugin database, since
>> not all plugins depend on Pidgin specifically (am I right?) so eg.
>> third party protocol plugins or plugins that don't depend on a GTK+
>> GUI would work under Finch and Adium and hopefully Vulture if that
>> gets off the ground this summer as well. Or should I just keep it
>> limited to Pidgin plugins in the beginning but say, keep a field in
>> the database for application, so that it can later be extended to
>> other libpurple clients?
>
> I've had some *CRAZY* and I mean **CRAZY** ideas for handling native
> plugins.  Mainly because we don't see many tcl/perl plugins, the python
> loader is, to the best of my knowledge still pretty new, and the mono
> loader has some issues that were waiting to get fixed in upstream mono.
>
> Anyways, these *CRAZY* ideas included something involving build
> environments for the more popular distros/archs, that would be built
> from a user supplied tarball, after it had passes some static analysis,
> and hopefully a code review.  Although this could be rather trivial to
> setup in our already configured, but barely used buildbot setup.
>
> However, it would be nice to have a simple way to diff the changes
> between versions if we were to do code reviews before we posted
> binaries, but that'd obviously get more complicated with larger plugins.
>
> Anyways, hope these ideas helped a bit...
>
>> --Ibrahim Awwal
>
> --
> Gary Kramlich <grim at reaperworld.com>
>
>

I think those are pretty cool ideas, but unfortunately I'm not sure
whether I can actually apply for GSoC anymore. I was reading John
Bailey's recent blog post on GSoC, and I realized that the time
commitment is essentially that of a full time job. This is fine for me
for about the first half of the summer, but during the second half
(July 5-Aug 15 or so) I will be traveling overseas and will probably
have only slow access to internet every other week. I would probably
only be able to dedicate maybe 20hrs a week max during those times to
the project, which I feel would be insufficient and/or unfair to
others working on projects.

In addition, in the times that I would not have internet access this
would become a very difficult project to do; even though I could run
an HTTP server locally, the likelihood of me needing to look things up
online is fairly high. Thus, unless you guys are really okay with a
lower amount of work during the second half, I won't apply for GSoC.

However, since this project is something that I'm self-interested in
and I do want to get involved with Pidgin long-term, I would like to
pursue this project independently during the first half of the summer.
I suppose there is always the chance that I could still do GSoC by
working extra hard while I was still in the US to make up for the
second part of the summer, but I don't know whether that would be
acceptable. If so, I *might* still apply but it is getting late and I
don't want to detract attention from other candidates who are more
likely to be able to work the entire summer. So I guess thanks, and
good luck with SoC, and hopefully I can get more involved with Pidgin
in the future.

-Ibrahim Awwal