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="doe...@eternalwondermaths.example.org"
url="http://eternalwondermaths.example.org";
/>
<author
name="His assistant"
email="namel...@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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
