[GSOC 2013] Easy plugins with a website

[Tomasz Wasilczyk]

2013/4/25 Mark Doliner <mark at kingant.net>:
> Looks good to me.  I think there are a lot of possible ways to
> implement the UI that we would be happy with.  The UI isn't the part
> of this project that I worry about.

You're right. Anyway, such mockup also enforces some features or
solutions to be done: uninstallation for user-supplied (non system
installed) plugins, auto-update mechanism, themes management (this
will also utilize fine amount of work).

> I worry about:
> - How to build plugins for a variety of OSes?  Windows is probably
> easy.  For Linux... would we statically link to dependencies?  Maybe
> for everything except glib and gtk?  And who should build the plugins?
>  Should we require plugin authors to upload various binaries?
> Creating an automatic build system that builds for Windows and various
> Linuxes is a significant amount of effort, and probably not worth the
> time.

I was aware of this before, but I somehow missed it now. In fact, this
may be the trickiest part of this project.

I think statically linking for everything except Pidgin/libpurple
dependencies (depending, for which one the plugin is) would be safe.
However, there still should be an option to distribute source package
to compile and install the plugin manually (as fallback). On the other
hand, compilation part could be automated on the client side, but the
implementation for it have to be really aware of configuration/build
errors. And still with fallback to manual compilation.

I have mixed feelings with allowing authors to upload binaries. They
are (as a whole) not as trustworthy as the Pidgin project, so
distributing their binaries from our domain could be not fair enough.
On the other hand, compilation from sources doesn't fix the problem
(these still could contain hidden malware). I definitely think, that
all (or all not marked as highly trustworthy) external (not
implemented and compiled by ourselves) plugins should be marked with
some warning, saying there is no warranty about such software.

Anyway, I think the following fallback chain would be fine: using
binaries (plugin's install callback would prove, that binary works) ->
automatic compilation from sources -> redirection to a page with
manual compilation instructions.

That means, we don't need to provide all binaries at once (except
Windows, I don't see any chance for automatic compilation here).

> - As a Linux user I try to only install software using my package
> manager.  Installing software via this interface would be hard to go
> through the package manager.  Installing plugins in ~/.purple/ isn't
> so bad... but it CAN lead to confusion if the user ALSO installs the
> plugin via their package manager.  If there are two versions of a
> given plugin installed, which one should we use?  We currently don't
> do a good job of messaging this problem to the user.

I think, user supplied version should be used. Anyway, if the user one
is older than the system one, there should be really intrusive warning
(in plugins window) issued. If the user one is newer or equal - polite
notice should be present.

2013/4/25 Eion Robb <eionrobb at gmail.com>:
> Not sure if I agree with this. Personally I think a usable plugins website
> is more important than client integration. Client integration in my opinion
> is an easy task if we embed the website in a webkit view in pidgin and a
> simple Uri handler could be used for remote install.

Please note, that client integration is not limited only to embedding
plugins website within a client. There are many hidden caveats, that
could eat the student (the one mentioned by Mark is one of these).

> I think there's a lot more work involved in a plugins website that works
> with multiple clients (eg finch and pidgin), multiple platforms etc.

I'm not sure, what are you talking about. Creating browser-compatible
webpage is easy these days, so I wouldn't worry too much. Distributing
binaries for multiple platforms is the hard one, but it involves both
client and website backend implementation (still without touching the
website UI - many students are pretty eager to just do the frontend).

> I don't think that we should be dissuading any students from submitting
> ideas for any projects that they are keen in pursuing.

I'm just concerned about the success rate - If the student won't be
aware about project complexity, he will do the layout in Photoshop and
he will be certain, that most of his gsoc task was done.

Tomek