Third-party service plugins

[Leonardo Franchi]

On Tuesday 21 April 2009 00:00:15 Seb Ruiz wrote:
> Hi all,
> I've been thinking that it would be a good move to start a sort of
> program/infrastructure for plugin developers to create extensions to
> Amarok. For the time being, specifically for services. I'm sure that
> we're going to get an influx of requests for services which are
> perfectly valid, but not going to be done because of either:
>   a) lack of developer resources;
>   b) lack of developer interest; or
>   c) target market is too niche to bundle with Amarok proper

Kind of like a cross between having it in-source (and well-supported) and be 
scriptable and obtainable through GHNS (but less well-integrated). 

> Scripted services are excellent, but do not expose enough
> functionality and are not flexible enough (with UIs, configuration,
> meta types, notifiers, etc)
>
> The perfect example of this is libre.fm, a foss last.fm clone
> (https://bugs.kde.org/show_bug.cgi?id=190213).

Not sure this is really a good example, libre.fm simply implements the 
audioscrobbler API, in fact someone said you can set libre.fm to be the 
audioscrobbler.net IP in your /etc/hosts and amarok will "librify" (heh) your 
track plays. 

> We could have an amarok-extras svn directory which would provide third
> party devs with all the resources they need to create their own
> plugins.
>
> It would be up to the developers of these plugins to do releases and
> coordinate translations etc, but could be easily packaged up by
> distributions as an amarok-plugins-extra package, for example.
>
> What we would need to do:
>   a) Setup an svn dir. (easy)
>   b) Provide initial infrastructure (build system, easy installation).
> (moderate)
>   c) Ensure stable ABI. We won't be able to get away with detours such
> as bumping a plugin version number since plugins will be externally
> handled. (hard)
>   d) Provide templates/tutorials for creating plugins. (moderate)
>
> Why we might not want to do it:
>   a) Lack of resources to get it off the ground
>   b) Too much work to maintain a stable ABI
>   c) Lack of interest from the community/third party devs

From me at least (a) seems to be the biggest obstacle. Nikolaj is the services 
guru so he will be able to say how (un)reasonable the the ABI freeze would be.

> ps - I've CC'd Matt Lee, who might be interested in such
> infrastructure to develop a Libre.fm feature.

Thats funny, someone just pointed me to libre.fm 20min ago.

leo
-- 
-----
lfranchi at kde.org		Tufts  University 2010
leonardo.franchi at tufts.edu                The KDE Project