A wiki’s page index consists of the name of each page on the wiki, hyperlinked to the page of that name. What you do, is you strip out all the hyperlinks from the page, and make those your name-url bindings.

I like it a lot, it makes it much more flexible, you could use practically anything on the web as your source of names: tags, dictionaries, web searches, directory listings, blogs. It’s so simple! – RadomirDopieralski

Yes, Oddmuse’s implementation will use the first more link. But luckily we’re not linking all words, so this is only a problem if you do in fact link to [[more]] which is rare. So effectively we’re just wasting some space, not corrupting the usability. Similarly, if you screen scrape a wiki’s page index, there will be some useless entries from the header and footer. It’s nice if wikis provide a dedicated list of links, such as these:

If you check the links, you’ll notice that A and B point to the same page using a different interface (English and German), whereas C points to a different wiki altogether. So assume that #1 is site A from the example above, and the definition for TEST on site C could be pointing to #2 or #3 – if it points to #2 we have an infinite loop; if it points to #3 we don’t. I don’t think it’s possible to build a system that will automatically do the right thing. Solutions will always be brittle.

InterLink using the InterMap – Oddmuse’s LocalName is a single “thing” a person types on a page; the resolver maps the whole thing to a single URI all-or-nothing. Oddmuse’s InterLink is a two-part “thing”; a different resolver maps the first part that the person types to a partial URI fragment, then appends the second part that the person types to build a complete URI.

Discussion

Making Sense of Different Sorts of Links

Well, InterLinks are explicit: MeatBall:AlexSchroeder points to the AlexSchroeder page on Meatball because I said so. AssumeGoodFaith points to a page on Meatball wiki as well, but not because I said so – instead, a little search strategy is used: First, we check whether the page exists here, then we go through the NearMap and check whether the page exists on any of those wikis, and if it does, we link there. Should we one day create a local copy of the page, the link will automatically point to the local page, since the search strategy looks at local pages first.

Lion’s system formalizes this, and provides a generic framework where you can link names to URLs in a namespace, and delegate the lookup to other namespaces if no local definition exists.

“FutureLink?” – actually, it’s not called “Future Link” in Local Names; it’s called "X FINAL" instead – that’s where a name goes if there’s no suitable binding.

Things you missed:

“this wiki” – there is no check for “this wiki” first, because there’s no such idea as “this wiki” in Local Names; if a wiki were to use Local Names, it would likely just produce it’s namespace description, and likely use that as the origin of it’s local names queries

NearLink – Local Names supports “near links” – if you query a namespace, by the “traditional” query style, then that implies a search of all neighboring namespaces as well (1 level deep)

Another thing to note about Local Names:

There’s no one specific way to look up a name, in Local Names.

Query servers can support multiple ways of looking up names. They should all have a “default” way, though, and they should all support the “traditional” lookup method. (Which is basically: 1. Look Here. 2. Look all Around. 3. Use X FINAL.)

This is so that the system can support all the different ways of looking up names: Do you want to be picky about foreign characters? Do you want to be picky about spaces? Do you want to be picky about capitalization? Do you want to search deep through the namespace web? Do you only want to search a single namespace, and nothing else, while still being able to perform namespace hopping? And so on.

Rather than construct an entire constraint based query language, I decided: “I’ll just let people name styles of lookup, and hand-code them into their query servers. People are going to be using traditional most of the time, anyways.”

local names- There is the scent of hearing somebody scatching. As if we dug tunnels towards each other. Local names and wiki-net. As if somebody scratches not far away and the tunnels are to connect soon. Just a September-scent.

InterLink, NearLink, LocalNames are for better connection and that’s fine. but i’m missing the backlink (another word for re-ligion (and this shows us how important it is)) . in my opinion each side has to have a main backlink (rc-tree rudiments) and a list of (perhaps weighted) backlinks (rhizome) .

Testing some more I added on CommunityLocalNames. It’s local names because every wiki cares only for its own local names. Care for your local names at home and use all local names yours included all over.

Ah, … so the situation is that you (A) link to someone (C) who links back to you (A), …

The problem seems endemic to redirects, period. Like email autoreplies in a war with one another.

I think the cheap solution would be to just point, and not try to resolve the chain. That is, if you are resolving a page on (A), then point it to (C). Leave it to the web browser (rather than the page renderer) to try and resolve the infinite loop.

The deeper solution would be – as you resolve the target, keep a list of the chain so far. When you get to a repetition, realize, “This is looping.” The only way it will go on forever is if the URLs generated are always different. (Which I could imagine – if unique random id’s are part of generated page URLs, or something.) But if it’s just /en and /de, you will exaust the supply at some point.

That would work. Since HTTP is stateless, and the wiki software we use (Oddmuse) is also stateless, I’d have to store the URLs visited in a cookie. That would only work if all the sites in the loop use the same software. Or I’d have to add state to the software.

Luckily there’s a cheaper alternative. The software has a SurgeProtector and it kicked in when I ran into the problem: I followed the Meatball link, load load load load load load load load load load (in other words, Firefox will not detect a loop), and I got the message Please do not fetch more than 10 pages in 20 seconds.

I think what we’re seeing is that the importing of entire namespaces instead of manually defining single names one after another results in a brittle system. We cannot control what remote sites will define, so other people will set up infinite loops for us.

When I wrote up the problem description, I had to invoke both NearLinks and LocalNames to describe the problem. But you are right, you can setup up loops using just one of these technologies. The key is that you are setting up an external redirect. Once you can do that, you can set up loops.

Importing tons of external redirects via NearLinks or LocalNames just enable you to shoot yourself in the foot using an automated rifle. X-)

You might modify the SurgeProtector to handle the loop special case – really, people shouldn’t be fetching the same page more than twice (once??) within the 20-second time frame, so the code could check for a repeat-fetch on a single page and report it as a likely loop.

When a user asks for page SillyName?, the rendering engine at A starts sending that page to the user. When it gets to the wiki-linked phrase “TEST, it first checks to see if “TEST” exists locally at A. Nope. Then it checks to see if “TEST” exists at B. Yes – so it renders that phrase “TEST” as a direct HTML link to page “TEST” at B. (If all the checks come back “No”, then the rendering engine puts the little question mark by it).

When the user clicks on “TEST”, he now goes directly to page “TEST” at B.

That page says something like “Sorry! There is no page TEST here at A. To create page TEST here at A, do this … You may be looking for page TEST over at B. … C tells me that there is a rumour going around that there exists a TEST page at this other URL …”.

The user could manually click on that last URL (that says it came from C) over and over again, and see that same 404 page (from A) over and over again. That would be confusing, but not disastrous.

That 404 page should give the user enough information to fix that confusion: (a) go to C, and fix their incorrect URL for “TEST” to point to a good URL; or (b) Remove C from A’s list of places to check for local names, and forget all the local names C already gave us, until C stops giving A nonsense; or (c) create the page “TEST” at A.

Hmm… I think this boils down to “don’t do external redirects if the request is not from the local site.” That makes sense. A will only redirect to B if the user followed a link from A. If the user followed a link from C and ended up on the non-existing page on A, then he’s not redirected any further.

Essentially this is what internal redirection using #REDIRECT already does: It passes along a parameter when it redirects. As it redirects, it checks for the absence of said parameter so that it will only ever redirect once.