Mesh Tool

Why use a dedicated tool?

• It can then have its own preferences and data.

  The data is easy: we need a database of stray link sources and targets so that we can optimise re-rendering. Why re-render everything, just in case, when we can instead re-render only the sources that matter?

  The same database could later be used for providing backlinks (which items link to this item?), optimising searching (think "microGoogle"), and so on.

  Preferences might include the order in which to resolve stray links, how slack to be in matching (exact match, caseless match, caseless match after discarding whitespace, sharing enough words to seem vaguely relevant, etc), and so on.

• We can cache loose identifiers outside of the tools hosting the items.

  A performance problem coming up is that the in-tool getCloudUrlMatchingStrayLink methods tend to scan through the entire database. Some of that is my sloppy code — why scan through weblog posts for post IDs when a straight query of the post database would do? — but caching identifiers munged in various ways would let us resolve any stray link with a single database query.

• We can move the match logic out of individual tools.

  I'm not sure what the pattern is, here, but if I want to update the match logic I want to be able to do it in just one place, not every tool.

• We can deal with ambiguous links.

  At the moment, the stray link matcher stops at the first link it encounters — but what if there were multiple suitable candidate items in multiple tools?

  If we have a dedicated tool for link resolution, we can react to ambiguous links by providing a link to an ambiguous link resolver based in the tool. The user can then select what they really meant, and the resolution tool can cache that choice.

• We can cache link definitions.

  Oh, boy, am I sick of defining a destination for Python_. Now, I could just put up a Wiki page entitled "Python", but I'm not that enthused about putting up an entire technical dictionary of tiny Wiki pages when having PyDS simply remember the last time I referred to Python_ would do the trick.

  If I did eventually decide to put up a Python page, of course, all the items would re-render to the new target. Excellent.

Naming

I've decided on MeshTool, mainly because LinkTool is already taken.

Implementation

I'll implement in multiple stages. First is to move the existing functionality into MeshTool (done). Then I'll get interesting:

• Rename getCloudUrlMatchingStrayLink. I think I went over this in WikiTool/ToDo, but we need one method for fetching an edit/target link (given context), and another for providing a link to an editing tool.

Progress

I've done that first bit, I think. We'll see. Grab MeshTool.py, WikiTool.py, and mesh1.diff and try it out!

[I really should have UpstreamTool offer automatic linking to filenames...]