[pmwiki-users] category analysis RFV

[Radu]

At 04:12 PM 3/16/2005, Patrick R. Michaud wrote:
>The hardest part of any caching system is knowing when to
>invalidate the cache.

True. I would leave it to the authors. Imagine a ToDo list, present on an 
author's page. There would be no reason for an author to refresh the list 
until s/he has not dealt with the tasks already displayed (bar urgent 
priorities, which can be done anyway manually or using a different 
semiautomation). If Author2 wants to attract the attention of the first 
author, Author2 could refresh the list on Author1's page.

>It's almost certain that PITS:00392, as written, will confuse
>a lot of people, because placing a page in a category doesn't
>cause the category page to be updated until someone does
>?action=refresh on the category page.  Or the net result is that
>readers will just be used to always hitting ?action=refresh
>in case nobody else has done it previously, in which case they
>get the cost of generating the page PLUS having to hit the extra link.

As I said, it's not my goal to make ALL lists rendered. Only the ones with 
low update rates or the ones on which continuous updates are not essential 
(as exemplified with the ToDo list example)

>And knowing to re-generate the page when someone has removed it from
>a category is even tougher (yes, there are ways to address this).

Oh, I see. You mean if someone edits the page with the list and deletes a 
link. I would say that's solved with a similar (-) link next to each item 
in the list, to be treated like the one on the link target page. If someone 
removes an item by editing, I'd say it would be there after saving.

Anyway, I still think that links should be removed at the destination 
rather than at the source. I.e., when looking at the index one may not be 
able to decide if a specific link belongs there, and remove it. That has to 
happen at on the page the index points to, just as it happens with the 
current, completely dynamic implementation.

>There are worse effects, because the rendering into the cache will
>depend on whatever authorizations are in effect at the time the rendering
>is done, but later viewers (who may have different authorizations) may
>then see results they're not authorized to see or miss results they
>are authorized to see.

Right now if I do Main.AllRecentChanges, I see all page links, no matter 
what passwords specific groups or pages have. Passwords have to be used 
only if I'm trying to see the page itself. But I see what you mean: with 
searchresults one could see if specific words are on some pages to which 
they don't have access.

Hm. If that's a problem, then to get the list we can just use the pass 
currently available on the page that does the searching rather than the 
pass of the current Author.

>I'm just of the opinion that caching isn't the way to go for dynamic
>results such as these -- a much better, more robust, and overall
>faster solution is to build a cross-reference index and use that
>to generate pagelists.  Searches will still be slow, but searches
>of specific sets of pages (groups, trails, categories) will be relatively
>quick and PmWiki really isn't a search engine.

Exactly because it's not a search engine I think it's not a good idea to 
build lots of searches into its common structure (like the current way 
Categories are handled) Yes, it's a good start, but more RDBMS-like than 
wiki-like. Thus slower.

*sigh* So I guess Pm doesn't think this is a good idea, so I'll have to 
make a recipe. When I get the chance. Thanks for the insights, though.


Cheers,
Radu
(www.monicsoft.net)