[rkward-devel] Downloadable plugins

[meik michalke]

hi,

am Montag 04 Oktober 2010 (20:15) schrieb Thomas Friedrichsmeier:
> 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.

you're right, btw. it did install to ~/.kde/share/apps/rkward/ -- i just 
didn't figure where to look.

> 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).

well, i'm ok with any directory as long as i find it ;-)

> I suggest to remove the version-specification until we actually need it

ok with me, if it works.

> > - some of this information should automatically be included in the help
> >   page(s) to the plugin, like version and author/maintainer
> 
> 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.

i guess i was thinking in slightly different terminologies all the time. i 
considered e.g. the IRT stuff to be one plugin which in turn consist of 
various dialogs. that is, to me the top level of a plugin was its pluginmap. 
in your terms, on the other hand, a plugin is at the XML file level, right?

anyway, i agree that author credits probably belong at the .xml/.rkh level. 
but may i suggest to perhaps make this either an override of the information 
in the pluginmap (that is the author defined in .pluginmap is taken as 
default, as long as nothing else is defined in a single plugin/dialog), or 
keep author information in the plugins/dialogs, and the responsible 
maintainer(s) of the whole "bundle" in the pluginmap? or both?

> > - <plugin />:
>
> Or we could merge this part into the "about"-element.

i like that.

> >  - rkplugin is intended for cases where one plugin uses parts of another
> >    plugin
> 
> This refers to a pluginmap, again, right?

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>
> ...

can you actually have <onetag <anotherone /> />?

> 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

i don't see how:
 o http://ghns.freedesktop.org/spec/ghnsdownload.dtd

> should we use separate repositories (one for "0.5.4 and later", one for
> "0.5.5 and later", etc.)?

perhaps we could use one repository but somehow solve this at the provider XML 
file level. i mean, at compile time we know which version of RKWard is in the 
making, so we could have it fetch the right XML file. this is perhaps not 
possible with the KDE repository, but i haven't looked into that at all.

> How will we handle repositories? In contrast to a wallpaper, it is
> trivially possible to ship malicious code in an RKWard plugin.

yes, that's an issue, indeed. i think this is not only a security matter, but 
one of quality and stability as well, because it will eventually fall back on 
RKWard itself if a plugin screws up the whole app. while it should be a piece 
of cake to install stuff, that doesn't mean it has to be as easy to offer it, 
in our case.

as long as we don't get trillions of new plugins, we could moderate/monitor 
plugin development still via the devel list. trusted contributors could 
release themselves, others need some kind of approval (this could be 
documented by the maintainer field in the pluginmap, as opposed to the author 
of a plugin). if that sounds too harsh:

> Will we have one repository for plugins which have undergone some sort of
> check, and another for completely untested plugins?

well, we could have a clearly marked experimental repository with easy access, 
and a revised one with checked and approved stuff. this could be achieved via 
two differently labeled buttons to get stuff (e.g. "install tested plugins" 
vs. "test experimental plugins").

btw, how about including plugin tests in the archive as well, would that be 
possible? i think it would help plugin developers a lot.


viele grüße :: m.eik

-- 
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at 40225 d"usseldorf
-------------- 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/1686852f/attachment.sig>