[rkward-devel] Dependencies and 'about' information for plugins

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Tue Feb 5 11:05:40 UTC 2013


Hi,

On Monday 04 February 2013, meik michalke wrote:
> oops, this will take some time, as it will require changes in several parts
> of rkwarddev. it will also break backwards compatibility, previous scripts
> will have to be changed (e.g., the "dependencies", "package" and
> "pluginmap" arguments of rk.XML.about() need to be transformed into a
> function of its own).

well, if it causes a _lot_ of trouble, that change is certainly debateable. My 
reasons were:
- It is a rather different kind of data, compared to the other info in 
<about>.
- Dependencies should always be handled in the .pluginmap for performance 
reasons: It avoids having to parse each individual plugin xml file on startup. 
In contrast, the <about> data can be lazy-loaded, later, and it makes some 
sense to allow it on the level of plugin xml files, too.
- The <dependency_check> shares its syntax with <dependencies>, which is 
another indication that this is a rather "independent" element.

Perhaps some (transitory) backwards compatibility could be kept, by keeping 
"dependencies", "packages", and "pluginmap" in rk.XML.about() with a warning, 
and smartening up rk.xml.plugin(map) to look at dependencies inside about 
data, if (missing(dependencies)).

> i will look into it. i'm not sure if this also requires rather complex
> internal changes. currently, the namespace "rkward" is hardwired in
> rk.XML.pluginmap().

One option might be to simply set namespace = name. It does not really have a 
meaning other than to avoid name clashes (internally, the id of pluginmaps 
becomes "namespace::id"). As it was not possible to <require> pluginmaps by 
their id, before, this should not cause any compatibility issues.

> well, the package needs a function for the new matrix element anyway. i
> hope it won't take me too long.

... and the new <optionset> element, and <switch> :-). Talking about the 
timeline, R 3.0.0 (scheduled for March/April 2013) will come with a few 
changes that will break RKWard 0.6.0. So we will have to target a new release 
of RKWard around that time, too. This could be a minimal maintainance release, 
but I'd certainly prefer a "real" release.

Don't worry, I don't have plans for any further new xml elements before the 
next release... (for the release _after_ that, I'd like to tackle the problem 
of querying R for information such as factor levels from inside a plugin).

> btw, XiMpLe and roxyPackage are on CRAN now, did i mention that?

Not as far as I remember. Cool!

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/20130205/3e9a3531/attachment.sig>


More information about the Rkward-devel mailing list