Smallest-Federated-Wiki opening a link in a new tab doesn't find federated content?

I have a newly installed wiki using the Sinatra server on Heroku with Cloudant. After following the instructions on the welcome page I clicked the "How To Wiki" link and started reading the formatting instructions (served from new.fed.wiki.org) for writing longer pages. So far so good!

After a while, I command-clicked the "How To Wiki" link to open it in a new tab, as I routinely do on many other sites. This opened a blank wiki page titled "How To Wiki", served from my server, and I was subsequently unable to access the "How To Wiki" content (served from new.fed.wiki.org) again.

I am still building my mental model of how SFW works, but I think that the logic that applies when I click a link normally should also apply when I open that same link in a new window or tab.

...

In this case, my understanding is that when clicking a link the client software will first look for a page with that name in the current wiki, and if it doesn't find anything then it will look in other (federated) wikis that it knows about for a page with the same name. I don't yet know what happens if your wiki is aware of more than one other wiki and they have different content with the same name :)

It seems that the more conventional wiki behavior of "the page doesn't exist yet, so let's create it" applies when opening a link in a new window. But once this has happened then it means that I can't find the federated content any more. I think this is a bug?

Jun 01 '12 22:06 RandomEtc

You defeat federated wiki's server searching algorithm when you open a page in a new tab. You could also be switching origin, but I don't think that is necessary for the behavior you describe.

It might be that we are too quick to generate an empty page when we don't find one. I'm open to suggestions as I've found the behavior you describe annoying myself. (A quick way to delete the unwanted page might be enough.)

Jun 01 '12 22:06 WardCunningham

Thanks for the timely response. Do you think my defeat of the algorithm means that there should be a better algorithm, or that I've misunderstood what the algorithm is doing for me and I should try harder to work within its limits? :)

I'm still catching up on the project history; reading https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Federation-Details now and also slowly starting to read the code. I'll also go back and watch more of your videos, because I think I missed something somewhere about the underlying principles. I welcome your guidance on how best to learn about the federated side of things and how content is chosen for display.

Jun 01 '12 23:06 RandomEtc

I can override the normal meaning of clicking a link. I don't know that I can override the browser behavior for opening a link in a new tab. Maybe I can. Do you know?

Here is TEDx talk arguing for overriding normal link semantics:

http://www.youtube.com/watch?v=BdwLczSgvcc&feature=plcp

Jun 01 '12 23:06 WardCunningham

You can certainly catch the click event on all a tags and prevent the link from being followed, in jQuery:

$('a').click(function(e){ 
  e.preventDefault(); 
})

This also catches command-click (which you can detect by looking at e.metaKey on mac, not sure on windows). However I'm not sure if it's then possible to trigger another action that would result in a new tab. If not then preventing it would be a bad thing, usability-wise.

A better solution could be to write the href of the a tag to give the new tab enough information to behave correctly, but I'm not sure what the initial tab has to hand that the new tab doesn't (regarding the requirements for resolving a page across the various federated sources). Yet. I will keep reading around!

(update: no need for return false in the jquery click handler)

Jun 02 '12 02:06 RandomEtc

I should say that I am a big fan of the stacking of paths and pages to the right as I navigate. And I really like the way this enables other widgets, such as charts, in the same browser window. I hope to play with this soon.

Playing around a little more, I now understand that navigating to /view/welcome-visitors does not load the same html from the server as loading /welcome-visitors.html.

And I understand that because of the on-demand nature of the search that happens when clicking on a link, you can't write the hrefs ahead of time to be the URL that eventually shows up when the link is clicked and the search completes. That's because clicking the link might result in navigating to a page that is sourced from another wiki. (Halting problem is a haunting problem... I never think it's relevant and yet, there it is).

Perhaps, when viewing e.g. /view/recipes, instead of href="pancakes.html" the link could be href="/view/recipies?q=pancakes". That way if there's no pancakes page on the current wiki, and it finally resolves as /view/recipes/friend.example.com/pancakes, then opening in a new tab would be able to resolve the same connections and show the exact same results?

The other loose end in this is that the .html representations would end up truly being for bots only, and never exposed to browsers with javascript active in a normal wiki reading session. I'm not sure if that's a bad thing or not, but it would make my issue #244 (the style of the journal in the html representation) largely irrelevant :)

Jun 02 '12 02:06 RandomEtc

I show what I know in the title text rollover for internal links. I could encode that for sure.

Best regards -- Ward

Sent from my mobile 503-432-5682

On Jun 1, 2012, at 7:40 PM, Tom Carden [email protected] wrote:

I should say that I am a big fan of the stacking of paths and pages to the right as I navigate. And I really like the way this enables other widgets, such as charts, in the same browser window. I hope to play with this soon.

Playing around a little more, I now understand that navigating to /view/welcome-visitors does not load the same html from the server as loading /welcome-visitors.html.

And I understand that because of the on-demand nature of the search that happens when clicking on a link, you can't write the hrefs ahead of time to be the URL that eventually shows up when the link is clicked and the search completes. That's because clicking the link might result in navigating to a page that is sourced from another wiki. (Halting problem is a haunting problem... I never think it's relevant and yet, there it is).

Perhaps, when viewing e.g. /view/recipes, instead of href="pancakes.html" the link could be href="/view/recipies?q=pancakes". That way if there's no pancakes page on the current wiki, and it finally resolves as /view/recipes/friend.example.com/pancakes, then opening in a new tab would be able to resolve the same connections and show the exact same results?

The other loose end in this is that the .html representations would end up truly being for bots only, and never exposed to browsers with javascript active in a normal wiki reading session. I'm not sure if that's a bad thing or not, but it would make my issue #244 (the style of the journal in the html representation) largely irrelevant :)

Reply to this email directly or view it on GitHub: https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/243#issuecomment-6074385

Jun 02 '12 04:06 WardCunningham

Why not mark the link as a ink to the remote origin server where data lies anyway? So "Open in a new tab" would open the link on its own native origin server, as would "Open link here" functionality bypassing JS present in some browsers.

Sep 15 '12 08:09 6e441f9c

Some good news. Earlier I admitted that, "we are too quick to generate an empty page when we don't find one." We are no longer so quick in most situations. In the open-in-new-tab scenario that started this conversation we now generate a 404 page rather than creating an unwanted empty page. Even better, when staying within the current tab, a a ghost page appears offering to create the page, if wanted.

More good news. The refresh/buildPage logic has more information now that we fetch-ahead sitemaps for sites as they are noticed in viewed content. That means that we could resolve the true destination for many links as they are rendered. Should a browser insist on interpreting the href literally, then it almost certainly end up in a good place.

In summary, the obnoxious empty page behavior is gone (except in obscure paths) and an efficient pre-search option is available that doesn't have us re-implementing browser meta-key interpretations.

Sep 15 '12 12:09 WardCunningham

A special purpose link syntax is still a good idea. I'm not sure I fully understood the suggestion @RandomEtc made four months ago. I may not fully understand it now.

Sep 15 '12 12:09 WardCunningham

Well, I am not sure what exactly he meant. What I would suggest is the following:

After rendering the new page start resolving the links as if they were clicked and cache the result. For each succesfully resolved link script will find out what page from what wiki would be requested. Then you could alter the acnhor element's href attribute to point to an URL that would instruct your wiki to pull that precise page from that remote wiki.

Of course, if all this is just considered lower priority than, for example, search - then it is another matter. And, probably, merging back forked pages is a more critical problem to solve..

Sep 15 '12 13:09 6e441f9c