Loading...
 

Tiki and PluginR


Coding an RR refreshing tool

posts: 68 France

Dear all,

Currently we use several tools for a group of experts to work on our databases online, See this document for more information : https://docs.google.com/document/d/1AAlNh3SgoMlp4rYlQLETDqvAK_B6Z11OJGPAZ1Quny0/edit?usp=sharing

We are quite stuck with some problems with the caching, so we will finance the coding of a tool to make things easier. Currently, once you have got a first image, you stick with it, even if the underlying data changed or if you changed the height / width. The only options are to change your R script, or to refresh tiki caches. Not very handy.

We need some strong tool in order to perform :

- Manual refresh with a simple click on a button located in the page to empty cached pictures and reload the page
- Refresh on a per-page basis : dumps the pictures and reloads the whole page (optioning to a per-graph basis : only dumps some cached pictures before the reload)
- An auto cache dumper / refresher time-based : each day, week, ..., it dumps the cache and the first user to load the page will create it for the others
- Has to work with R, RR, spiralstatsfilter and potential other tools of the R family
- Enable/disable cache per user or manage other caching options : no caching, caching...
- Option to output the date of the picture at the bottom of the graph.


A R stats refresher plugin


The idea would be to create an independant plugin (R_stats_refresh) which basically provides a button to click to dump the old pictures of all R-type instances and to reload the page.

Then some options would be great :

- Dumping the pictures based on their time-stamp : for instance, before or after page load, dumps the cached pictures too old (compares the date of the picture to the date of the last database extraction)
- Refreshes only the image before the plugin - see if it can spot a cached picture, depending on time and naming...

An other option could be to include the code in RR to make it an option of RR. That would make simpler the per-image refreshing. But a per-page refresh is more essential. We won't ask our user to refresh the page as many times that there are pictures in it...

So what do you think of this ?

posts: 1779 Catalan Countries
why not integrating this as options inside the PluginR?
posts: 68 France

The problem is that in the case of several RR plugins in a page, you will need to refresh each one separately...

And second reason, we can test it without impacting RR...


posts: 28 France

I think some choices of caching strategy would be nice on Plugin_RR, like :

  • no cache (nice until you finish debugging this R script)
  • per user (this seems required for R scripts which show something different for each user, and very bad for other scripts)
  • simple cache (current behaviour: the cache is forever)
  • time-limited cache. With another option of choosing duration in seconds?



If this is done correctly, will there still be a need for the user to refresh all pictures at a time ? I guess yes: when data changes, Plugin_RR does not know about it :-(


posts: 28 France

About the idea of a Plugin_R_stats_refresh which refreshes all R and RR plugins in the page, I am concerned about the potential for denial of service attacks:
Anyone who clicks on the button will force a lot of computations on the server. If someone does a script which simulates clicking on it, the server is likely dead.

So we would need some kind of new permission for this maybe ?

posts: 1779 Catalan Countries
yep, a new permision seems that would solve the issue with bots launching the cache refresh.
posts: 68 France

You're right.

This said I was considering embedding it in the plugin GROUP to force to define a group of users capable of viewing the tool. This could be a mandatory option for the plugin to work, with a check that mobody adds the group "anonymous".

Another option might be to recycle an already existing permission, like tiki_p_list_trackers, to attribute to registered users.

But if it is not a problem, creating a new R category of permissions might be great. Other than that I can't figure out where to put this new permission.

I guess Jyhem will have the last word about the best option :-)

posts: 28 France

At least, I made the refresh icon a POST instead of a GET. This way, people will not end up with URLs containing &rrefresh=y and pass them around, effectively forcing cache rebuilds all over the place, and destroying performance.

No time for the permission thing, sorry.

posts: 68 France

We will see this on the long term... Thank you Jean-Marc !

For now, let's trust our wikispiral.org users to refresh when they need.

Thi said, in wikispiral you could change the checking for another group, for instance GC (groups with registered data); but right now I son't see the point of doing so.

Let's test this in real use for a while and see!


Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.