[rkward-devel] a new approach to external plugins

[meik michalke]

hi,

am Mittwoch 10 August 2011 (19:05) schrieb Thomas Friedrichsmeier:
> all of that sounds quite straight-forward, and maybe you are right that
> this should eventually become the _only_ supported way to distribute
> add-on plugins. However, I am a bit reluctant to remove the GHNS-based
> approach just yet. Let's wait until we have all the bits in place, first.

sure, no need to push things. and it's not that i think the GHNS way is bad. 
this is more like a by-product of me trying to get things in sync, it just 
never occurred to me before that a plugin archive could also be an R package 
at the same time.

> Well, we need this information in the frontend, not in R (at least as far
> as I can see). Therefore I think that keeping it in XML, and inside the
> pluginmap, is still preferable. Also, the XML in the .pluginmap is going
> to stay, so I think moving some bits to a (new) DCF based file would not
> really help to make things more simple.

that's a point. of course i didn't want to remove XML from the pluginmaps, 
only the parts that were added because of the external plugins.

> You mention producing this info by a script, and I think it would really be
> a good idea to have something roughly equivalent to package.skeleton() for
> rkward plugins, indeed.

yes, that was exactly where i was going. it would also be nice to have a 
simple dialog for that, where you could type in some basic info.

> However, I think producing this in XML format is not really _that_ much
> harder to implement.

let's say: it's absolutely possible. but it can't get much easier than giving 
a data.frame to a function of R-base, and read it back the same way, i guess.

[i used some stuff from the XML package in one of my packages, which worked 
great, but i had to throw it out again after there was no windows binary 
available for some time, as it turned out after i received support inquiries 
from people who couldn't update my package (it was a limited thing, i wrote my 
own parser then to get rid of the dependency again). is there any XML support 
in the base installation? if not, we'd have to write it ourselves, if we need 
it, e.g. to create a package skeleton.]


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 d-40204 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/20110811/bce90caf/attachment.sig>