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