incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Metske <>
Subject Re: PageViewPlugin
Date Mon, 31 Aug 2009 17:03:25 GMT
2009/8/31 Janne Jalkanen <>

> > Keeping the data as property of the page would break the performance of
> the plugin.
> > (and would make a sliding behaviour like dividing all counts by 2 every
> time period
> > that much more difficult to implement)
> Not really; would be really easy to find them all with an XPath query.
> The bigger problem is that they would probably kill read perf because
> it would result in a DB write for each read.

not necessary, we could still use the current (in memory) caching mechanism.
We should then keep delta values there, and after interval expiry, read the
pagecount value from the JCR node for each entry from the im-mem cache, add
the delta values and write back to JCR.
This does assume that we have locking capabilities on the JCR page.
This way we would also support multiple wiki instances.


> > Originally I opted against putting the data in a generated wiki page
> because it will
> > get in the way of people. An attachment to a special page like
> PopularPages also
> > did not seem the way to go - replacement bypassing the versioning of
> pages and attachments
> > breaks the general behaviour.
> For JCR this is not a problem, you just put it in a non-versioned
> Node.  It would both be invisible to the generic user, and also it
> would not mess up with anything.
> I think JSPWiki currently ignores any namespaced Nodes in the main repo.
> > With regard to context; one would expect a count per space if spaces are
> separate
> > wikis.
> Well, a WikiPath is a combo of spacename and wikiname, so you would
> probably use that.
> /Janne

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message