Smallest-Federated-Wiki icon indicating copy to clipboard operation
Smallest-Federated-Wiki copied to clipboard

can I really only communicate with one other fed-wiki?

Open SvenDowideit opened this issue 12 years ago • 4 comments

I'm finally reading the in-wiki docco, and the linking seems un-federated to me.

I appear to have a choice of linking to my pages, and my parent wiki's (Site of Origin) pages, and external links.

having bumped into Phil Jones via my pull request, I wanted to link to his wiki, and then read a few of his pages while possibly forking some - as this is how i would think of federated - everyone in a web of wiki's.

do i need to read the code, then update the docs? or am I heading off with the faeries?

yes, I realise that I can put

http://localhost:3000/view/welcome-visitors/thoughtstorms.info/howsfwchangeswiki

into my URL, but is there a proper syntax for this?

[[thoughtstorms.info/howsfwchangeswiki]] 

perhaps?

SvenDowideit avatar May 02 '12 12:05 SvenDowideit

ok, and that might be a bug

http://localhost:3000/view/welcome-visitors/thoughtstorms.info/howsfwchangeswiki

shows Phil's page, but when I then click on any link, it gives me an empty journal with the flag showing its from his wiki.

(express server - I guess if I'm going to play with this / search / whatever, i'm going to have to make a ruby vm too)

SvenDowideit avatar May 02 '12 12:05 SvenDowideit

I figured out what is going on here. Phil authored much of his content using a plugin you don't have. That means your origin, localhost:3000, can't render it as Phil intended. If you click on his flag (favicon) you will reload with his site as origin and reap the benefit of his custom plugins.

The default behavior for uninstalled plugins should be to acknowledge the situation, perhaps as follows:

Can't render WierdoPlugin content.

Since we can expect json pages to move through the federation faster than the plugins that interpret them we should expect this to be a common occurrence. We could retrieve the plugin from the remote site but don't want to spread viruses that way. We could, however, retrieve inert json from the remote plugin directory that could be useful in explaining the missing plugin. In that case the error message could read:

Can't render WierdoPlugin content. Learn more ...

Expanding the plugin format to be a subdirectory opens the door to this sort of behavior. Hopefully every plugin will have a Learn More page that explains how to clone the plugin from some git repo somewhere. (But don't think of making this last step automatic without some sort of javascript sanitizer.)

WardCunningham avatar May 02 '12 14:05 WardCunningham

I'm curious about that syntax question as well...

EliezerIsrael avatar May 06 '12 16:05 EliezerIsrael

The link that Sven asks for, a link that specifies both a remote site and a page name, exists as a unique kind of paragraph (more correctly, a unique story item type). I think of these paragraphs as citations like those that appear in a bibliography.

As a complete item, these citations are manufactured by the factory, through drag-and-drop, not by markup in another paragraph. (Warning: the current drop handler implementation only works with some browsers. Try chrome on osx first.) The factory will go so far as to retrieve the remote page and extract an initial paragraph as the body of the citation. I hope authors will learn to write their initial paragraphs accordingly. For those who don't, you can always double-click the weak citation and revise the words to meet your needs.

The sinatra server's recent-changes mechanism creates citations too. You can call up recent-changes on a remote site and start browsing from there. (Hint: click the flag, not the link, if you want to bypass local copies of remote content.)

WardCunningham avatar May 06 '12 17:05 WardCunningham