Foswiki on GitHub is open for business! Next release meeting: Monday October 13, 1300Z

Item10677: CompareRevisionsAddonPlugin doesn't set $NO_PREFS_IN_TOPIC

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Urgent Closed Extension CompareRevisionsAddOn  
so thats 3 pointless topic access every operation (almost doubling the number of topics needed for a raw=all view).

  1. CompareRevisionsAddon
  2. InterWikiPlugin
  3. SmiliesPlugin

sadly, because of the way it works (legacy wise) these topics are read and parsed even when doing a raw topic view - ie, when its not needed at all.

imo we should change this - that way http://foswiki.org/Main/SomethingSimple?raw=all= would only need to access 4 topics (or even less really)

  1. siteprefs
  2. the last editor's topic
  3. webprefs
  4. the topic...

we should probly consider inverting the default some time.

-- SvenDowideit - 25 Apr 2011

I don't see that CompareRevisionsAddOn or CompareRevisionsAddonPlugin actually use any preference settings. Probably safe to change this one.

InterWikiPlugin contains our $NO_PREFS_IN_TOPIC = 1; in both the release11 and trunk versions. Are you sure about this one?

Same for the SmilesPlugin - both trunk and release11 have the our $NO_PREFS_IN_TOPIC = 1; set.

-- GeorgeClark - 25 Apr 2011

I will take care of CompareRevisionsAddonPlugin.

The two other by design must read the topic that defined the smilies and the interwikis to build the regexes that then search for the patterns in the text. I cannot see how we can avoid this.

It may however make sense to build a cached regex for both instead of parsing the two files which takes time.

It requires a trigger mechanism that rebuilds the cache when people add new interwikis or smilies. But that cannot be so hard to do. Both plugins could simply do this in a save handler. If its setting file is saved then update cache.

If we put the plugin version in the cache file the plugin can upgrade its cache when the plugin is upgraded.

We have successfully done this with the language list and we could also go the same with the list of webs.

-- KennethLavrsen - 16 May 2011

I have fixed the CompareRevisionsAddonPlugin

The two others are confirmed to not check for plugin prefs. But by nature these plugin read the smilies and interwikis and I cannot see a way to avoid that with the plugins active.

We can optimise by making them with a small cache but by nature one way or the other the two plugin need to check the topic for smilies and interwikis at each page view.

I am setting this report to WaitingForRelease.

It should be separate bug items to figure out how to optimize the the two other plugins. This plugin needs to be closed for 1.1.4.

-- KennethLavrsen - 17 May 2011

brilliant, thankyou smile

-- SvenDowideit - 18 May 2011
 

ItemTemplate edit

Summary CompareRevisionsAddonPlugin doesn't set $NO_PREFS_IN_TOPIC
ReportedBy SvenDowideit
Codebase
SVN Range
AppliesTo Extension
Component CompareRevisionsAddOn
Priority Urgent
CurrentState Closed
WaitingFor
Checkins distro:a2831af5c7d0 distro:86963990ea00 distro:8424ed550836 distro:bcb1d5b6fd6e
TargetRelease patch
ReleasedIn 1.1.4
Topic revision: r11 - 17 Dec 2011, GeorgeClark
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License