[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