[rkward-devel] a new approach to external plugins

[Thomas Friedrichsmeier]

Hi,

On Wednesday 03 August 2011, meik michalke wrote:
> i mean, why not simply have R's packaging system
> manage RKWard's add-ons as well? it souldn't be too hard to let RKWard
> scan (newly installed) packages for 'rkward' subdirectories with
> pluginmaps, maybe use a special 'src/Makefile' target to add pluginmaps
> automatically somewhere (which should even work in plain R), or even still
> leave it to GHNS.

it would probably make sense to add support for this, indeed. However, the 
current mechanism should certainly stay: Plugins are not necessarily tied to a 
specific R package.

Let's think about the details a bit: I'm sceptical that a Makefile based 
approach will work reliably across systems / platforms. Of course, if you can 
make it work, go proove me wrong.

So then the follow-up question is: When should rkward scan for new packages 
with pluginmaps? I think there are three options:
1) Whenever a new package is installed / updated using RKWard's package 
management UI, scan that package for new / updated .pluginmaps.
2) Option 1 and additionally once at the start of each session (to cover 
packages that were installed outside of RKWard).
3) Every time a package is loaded, scan only that package for a pluginmap.

Option 3 has the advantage that it should be very reliable. On the other hand, 
the pluginmap will not be added, until the package is loaded for the first 
time. Option 2 should cover almost all use cases, but I'm not sure about the 
overhead of that. Option 1 should not add much overhead, but will miss 
packages that are not installed using RKWard's package management UI.

Thus, I guess the key question is: How costly is it to scan installed packages 
for pluginmaps? Would you like to give that a try?

Regards
Thomas

P.S.: RKWard currently runs installed.packages() on each session startup. When 
many packages are installed, that can cost several seconds, esp. while the 
disk cache is cold. Perhaps this pain could at least be shared (unless you find 
a way to work around it, completely):
a) If the fact that a .pluginmap is supplied could be listed in the 
DESCRIPTION-file somewhere, the scanning-mechanism could simply rely on 
installed.packages, too, thus sharing the cost. I'm not sure, whether custom 
fields are allowed in the DESCRIPTION file, though, or whether "Enhances: 
rkward" would be a "legal" representation.
b) If you start from scratch, instead: If your scanning mechansim would return 
a list of all installed package-names as a side-effect, that info could be used 
to speed up the start-up.
-------------- 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/20110808/69c6d872/attachment.sig>