[pmwiki-users] category analysis RFV
Radu
radu at monicsoft.net
Wed Mar 16 16:07:39 CST 2005
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)
More information about the pmwiki-users
mailing list