[pmwiki-users] Greedy targets= with trails?

[Martin Fick]

On Mon, Nov 21, 2005 at 10:57:31AM -0600, Patrick R. Michaud wrote:
> On Mon, Nov 21, 2005 at 11:47:01AM -0500, Martin Fick wrote:
> > > Well, while the pagestore could potentially extract the title
> > > without too much expense, having pagestore figure out the
> > > targets= attribute would be *very* expensive and would affect
> > > the whole system.  
> > 
> > Hmm, are you suggesting that this would be expensive for
> > other reasons than pagelists?  It seems like it would be a
> > vary small hit for evey page load unless a page were
> > extremely larege in which case the hit would not seem
> > unusual would it?
> 
> At the moment, the only way to somewhat reliably figure 
> out all of a page's targets is to render the page through 
> MarkupToHTML (this is what the edit routine does when saving
> the page).  That's fairly expensive to incur on every page
> read.
> 
> It's possible that we could come up with optimizations to
> MarkupToHTML to be able to let rules specify when they
> need to be activated and when they can be skipped, but
> it's still a lot of overhead to attach to every page read.

  But who is using that info on individual page reads?  Does
the list of links need to be known before calling
MarkupToHTML to actually render the page?  Or, are we
talking about searches again (pagelists)?

 
> > I don't see this as a problem since I would consider having a 
> > trail on page similar to having an include on page, while it
> > might be nice, pmwikie doesn't save links on included pages does
> > it?
> 
> No, PmWiki doesn't consider links in (:included:) pages to be
> targeted from the current page.  I hadn't decided yet if
> trail links should be treated like included pages or not.
> 
> > > Another approach would be that updating a
> > > trail causes the targets= links for all pages on the trail
> > > to be automatically recalculated.
> > 
> > I think that this solution would be rather difficult to manage.
> 
> Oh, it's not pretty but it could be done without too much
> trouble.  It's just another custom function in the edit+save
> sequence-- all it would have to do is ReadTrail on the current
> page and then go through and update the targets= for each page
> in the trail.

  To me this is just an even bigger spagetti indexing mess,
fine if it's unpluggable. :)