[rkward-devel] Downloadable plugins

[Thomas Friedrichsmeier]

Hi,

On Monday 04 October 2010, meik michalke wrote:
> Am Samstag, 2. Oktober 2010, 20:51:02 schrieb Thomas Friedrichsmeier:
> > I assumed it would install to ~/.kde/somewhere, but I had not tested.
> 
> hm, i'll check that. anyway, as a user i'd assume the RKWard config
> directory would be the obvious place to store its plugins, too.

I guess that means we would have to make the .rkward-directory hard-coded 
instead of configurable, since we can't change the .knsrc at runtime (probably 
not an issue, though).

> > Why don't you make a start and add such meta-info to the .pluginmaps?
> > I.e. make a list of useful info, decide on how to decloare this info in
> > the .pluginmap-files, and update the documentation, accordingly?
> 
> ok, before this is added to any documentation, i'd like you to have a look
> at this first proposal and speak your mind. the thing is, when this is
> added to a .pluginmap, RKWard as of now skips the whole plugin:

You'll have to move the <about>-element inside the <document> element, then it 
works.

> some comments:
> - i versioned the <about> section, so that if at a later point we see the
> need to change anything, i.e. add one tag or rename another, that wouldn't
> automatically break old plugins.

Adding tags is not a problem anyway. I suggest to remove the version-
specification until we actually need it (and then we can compare "no version 
specified" against some specific version) to keep things simple.

> - values inside an argument should be separated by commas, if needed

Or you could repeat the element. Makes sense at least for <author>.

> - some of this information should automatically be included in the help
>   page(s) to the plugin, like version and author/maintainer, so that bugs
> and requests don't spam the devel list. even if no help page was prepared
> on its own, RKWard could generate one with basic support information from
> this section.

Hm, in principle, I agree. However note that a pluginmap may not correspond to 
a single plugin. And in fact most (all?) pluginmaps in the official release have 
plugins of different authors. So this information should be defined at the level 
of each plugin.

Probably it still makes sense to repeat this information at the level of the 
pluginmap, though.

> - <plugin />:

I'd suggest to call this "pluginmap" or "collection" for the same reason. 
(pluginmap is more consistent with current terminology, collection might have 
been a better term in the first place). Or we could merge this part into the 
"about"-element.

>  - releasedate might be redundant, but maybe nice to have, so i'd vote for
>    "optional" here
>  - the category should be freely definable, but might be used to later
> group plugins in the configuration dialog etc.
> - <dependencies />:
>  - these should all be optional, but might be needed for certain plugins
>  - the repository argument is probably the most delicate one... but since
> some packages do reside in places that are probably not defined by the
> user yet, there should be some way to at least communicate that. i'd
> propose a warning message at plugin installation time like "this plugin
> depends on package Foo, which is not installed. if you proceed, the
> following repositorie(s) will be added to your repository configuration.
> the required package(s) will be installed the first time they are needed."
>  - rkplugin is intended for cases where one plugin uses parts of another
>    plugin

This refers to a pluginmap, again, right?

I'd suggest to change a few details as follows:

<document base_prefix="" namespace="rkward"
       id="something unique">
 <about
       name="Square the circle"
       shortinfo="Squares the circle using Heisenberg compensation."
       version="0.1-3"
       releasedate="2010-10-04"
       url="http://eternalwondermaths.example.org/23/stc.html"
       license="GPL"
       category="Geometry"
   >
   <author
       name="E.A Dölle"
       email="doelle at eternalwondermaths.example.org"
       url="http://eternalwondermaths.example.org"
   />
   <author
       name="His assistant"
       email="nameless at eternalwondermaths.example.org"
       url="http://eternalwondermaths.example.org/staff/"
   />
   <dependencies
       rkward_min_version="0.5.3"
       R_min_version="2.10"
       <package
          name="heisenberg"
          min_version="0.11-2"
          repository="http://rforge.r-project.org"
       />
       <package
          name="DreamsOfPi"
          min_version="0.2"
       />
       <pluginmap
          id="..."
          url="..."
       />
   />
 </about>
...

Some other things:
Defining the minimum version of rkward in the pluginmap makes sense. Still it 
would be nice to know whether a downloadable pluginmap can be used with the 
current version of RKWard *before* downloading it. If this cannot be 
represented in the GHNS meta-data, should we use separate repositories (one 
for "0.5.4 and later", one for "0.5.5 and later", etc.)?

How will we handle repositories? In contrast to a wallpaper, it is trivially 
possible to ship malicious code in an RKWard plugin. This should not keep us 
from making it easy for users to install third-party plugins. But will we 
screen each plugin for obviously evil things before allowing it into the 
repository? Will we show a very general warning that *any* plugin could wipe 
your bank account and harddisk? Will we have one repository for plugins which 
have undergone some sort of check, and another for completely untested 
plugins?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20101004/aa72138d/attachment.sig>