On Tuesday 14 October 2014 12:44:09 meik michalke wrote:
> Am Montag, 6. Oktober 2014, 20:28:45 schrieb Thomas Friedrichsmeier:
> > - Providing better control over which plugins are active. I'm still not
> > convinced, the level of individual plugins is (typically) the right
> > granularity of control, but in fact, control should be more fine-grained
> > than  the current "official" pluginmaps, and esp. more fine-grained than
> > simply using all.pluginmap, by default.
> are there R functions yet to enable/disable plugins? you know, if there
> were, in combination with rk.list.plugins() i could simply write my own
> plugin for that control.
> a function which lists all meta (like <about>, <dependencies> and info on
> the menu structure) information on plugins would also be great, because the
> name alone doesn't explain so much.

interesting idea. But no, rk.list.plugins() is the only piece of that picture, 
that exists, so far.

Let's keep it in mind for 0.6.3. (Although I'll start by working on plugin 
i18n; that's long overdue at any rate). And when I say let's keep it in mind, 
I mean: Do remind me!

BTW, including (incubating ;-)) rk.power (and other) external plugins will 
have to wait for 0.6.3, too. As you can see, I did not make any further 
progress, yet, and we're just too close to release time, by now.

Further BTW, the code that's going to become 0.6.2 is in a separate branch, 
now. SVN trunk is open to "riskier" commits, again.


Attachment: signature.asc
Description: This is a digitally signed message part.

Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
RKWard-devel mailing list

Reply via email to