GSoC 2012 : Pidgin Plugin Website

[John Bailey]

On 03/25/2012 03:45 AM, Mark Doliner wrote:
> This isn't clear.  I'm sure different people have different opinions...
> 
> Personally I think it makes sense for plugins to be viewable on a
> website.  Having them also viewable within Pidgin doesn't seem
> necessary to me.  After all, why should Pidgin duplicate functionality
> from a web browser?  However, it kinda depends on how the plugin is
> installed.

With our use of Webkit in 3.0.0, not so much would be duplicated, as we could
tell Webkit to go fetch the page(s) on its own, but I'd rather see this
particular piece as a plugin.

> Ease of use of plugins has never been great on Linux.  And packaging
> to make plugins easier to use is probably a burden for plugin authors.
>  I don't know whether it makes sense to lump these tasks in with this
> project, but someone may want to consider ways to make this process
> easier.

Plugins aren't always the easiest things to use on Windows either.  For example,
I don't have a functioning Windows installer for the Purple Plugin Pack, so I
distribute just a zip file containing all the .dll's.  This is apparently a
difficult concept for some people, even though there's a readme included in the
archive.

I've mentioned a setup for plugin distribution before, and I'll repeat it here
for the sake of reminding people, but it's probably outside the scope of an SoC
project.  (The scope can always be changed if needed.)  My idea for plugin
distribution was to steal a page from Adium, OpenOffice, et al, and have our own
custom file extension that we register on Windows (and if it's easy enough,
maybe register with GNOME and KDE on non-Windows platforms as well).  I'd
suggest the route of simplicity here and use a simple zip file with its
extension changed.  Inside the zip file would be a structure identical to
.purple's layout, so the plugin's binary would be in a plugins directory inside
the zip file.  If the plugin uses its own files or a SQLite database or
something, copies of these files containing default settings could be included
in the zip file as well.  If we provide install ability though, we'll probably
need to have an uninstall capability too, which would likely mean we need to
have some sort of manifest in the zip file so we can know what files to remove
on uninstall.  Some code in Pidgin to handle the file (which on Linux could be
some sort of script instead of functionality built into the pidgin binary if we
want), and it's done.

The hard part with the above is making sure the right "package" is used in the
right place.  For example, a binary for Fedora 13 or 14 or whatever is out there
may not work on Debian or Ubuntu due to library version differences.  Of course
the same would apply to BSD users, as well.  This *may* be something that can be
partially ironed out in javascript on the site, though.

> For example, for Linux users, maybe they could download a .c file, or
> a zip containing the source, and Pidgin automatically invokes gcc,
> compiles the plugin, installs it in the user's local ~/.purple/
> directory, and cleans up after itself.  It would need to show friendly
> messages if the user needs to install gcc, or needs to install the
> pidgin-devel rpm or pidgin-dev dpkg.  And it would need to be able to
> check for updates and update the plugin, possibly automatically.

I have no strong opinion on this either way, but I would like to point out that
this has the potential to be a disaster area.  There are security implications
surrounding downloading and automatically compiling random code, even if it is
from a website we intend to be trustworthy.  My instinct is to lean toward being
against the autocompile idea.

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20120325/c6742f49/attachment.sig>