Discussion: Federation Standard

[jhulten]

I realized what has me scratching my head. What is the minimum required to federate? What do other servers expect?

As I understand it all you need is /.json and to respect the transfer format. Am I missing anything?

[WardCunningham]

Yes, you can serve content into the federation serving only static .json pages that you prepare by some other means. Here is a GitHub Repo for perl scripts I use to translate Eric Evans' Domain Driven Design patterns from a word file into static .json files.

You would need to do more if you want to be an origin server: things like serve up the javascript, css, and starter html. There could be limitations for drag-and-drop of static pages into the factory plugin. Another origin server assumption is the ability to click a page's icon and get to its origin server. No origin, where does that go? It might be possible to configure Apache to do all that is required. A writeup on how to do that would be awesome.

You have to do even more if you want to support editing. Maybe supporting editing it no important in some situations.

It would be cool if the flat-file repository format were Apache compatible so that one could edit privately and then push static content to a normal web server.

[GerryG]

I think that's what he's asking. What are the functions of an "origin" server, obviously that is more than just serving the json.

Correct me if this is wrong, but I would think serving the json is what is necessary to drag content from your page to a "factory", which is how you take content into SFW.

It would be really helpful to have a clear picture of some typical "life-cycles" of a page as it gets dragged and dropped, changed and then have those changes incorporated back to the original page. I'm getting that this isn't totally defined, and some of it is intentionally open until we see what needs show up. When does it get identities of different kinds (page names, "slug"s and so forth)? What is tracked in the journal and how?

[WardCunningham]

A while back I drafted some life-cycle scenarios in Federation Details in the GitHub wiki.

[interstar]

So, suppose I have a bunch of static json files on a server. How do I now reference them from a live SFW page in such a way that they get pulled into the federation?

[WardCunningham]

Here is a simple path. Say I go to the url:

http://my-server.com/view/foo/your-server.com/bar

Then I will see two pages, foo from my server and bar from your server. If I edit bar, then bar gets written to my server as mine and has a link in the journal to your bar which is my "attribution".

Issue #70 discusses more ways to find pages distributed on multiple sites.

[interstar]

OK. But what does my "static" server have to be? If, for example, we're talking about static files served on a basic hosting service, the path to them might not be as simple as "domain.com/pagename" ... it's going to be more like "domain.com/long/convoluted/path/pagename" Can we handle that?

[interstar]

Also ... is it possible with a purely static file host to let people download a client and browse the static files via it, even if they can't edit? Ie. to launch a client looking at a static welcome page?

[WardCunningham]

Yes. Here is a federated wiki site that is rebuilt every five minutes with a cron script:

 http://sensors.c2.com/

Notice that it doesn't have a login. Its read only, meant to feed into other people's wikis. However you can still edit it and your changes will be stored in the browser.

[interstar]

Hmmm ... I'm still not sure I'm following. I've put a bunch of converted static json files on my server.

You can now access them through the right sort of url eg. http://sfw.thoughtstorms.info/HomePage

But if I try calling a URL on my local dev server of the form : http://localhost:3000/view/welcome-visitors/sfw.thoughtstorms.info/homepage then nothing appears and I get the following error from the server :

remoteGet error: { [Error: getaddrinfo ENOENT] code: 'ENOTFOUND', errno: 'ENOTFOUND', syscall: 'getaddrinfo' }

Should this be possible?

[WardCunningham]

Code was added to the client to decode those multi-page urls. I'm guessing that there is some configuration detail that was never documented. I'd love for you to figure this out and document it. I'd also forgive you if you launched one of the interactive servers just to keep your project simple.

[jhulten]

Any wagers on if the code is expecting the .json extension?

Jeffrey Hulten Principal Consultant at Automated Labs, LLC jeffh@automatedlabs.com 206-853-5216 Skype: jeffhulten

On Mar 16, 2012, at 4:41 PM, Ward Cunningham wrote:

Code was added to the client to decode those multi-page urls. I'm guessing that there is some configuration detail that was never documented. I'd love for you to figure this out and document it. I'd also forgive you if you launched one of the interactive servers just to keep your project simple.

---

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

[interstar]

Ah ...that was it jhulten. I've changed my host-script to remove ".json" from the end of the request.

Ward I'm happy to document this. Currently added to the end of https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/Hosting-and-Installation-Guide

I'm wondering how much further it might be worth developing the PHP into a simplified SFW server. I don't have root on this host so setting up something else is a bit more complex.

[WardCunningham]

Is that all it takes to make a read-only (publishing) server. I notice that my sensors.c2.com does not handle browser history correctly. That could be from using old javascript. Does everything work for yours? You've chosen a good place to document it. You might add a SHA for the javacript version you've tested. We're a moving target and not mechanically testing code in the GitHub wiki.

A bigger step would be to support a read-write server in PHP. The strategy here would be to get the integration tests running and then add PHP code until they are all green. This would imply you were supporting the evolving client-server protocol as well as the much simpler federation protocol.

[interstar]

So that way of serving static pages works ... but ...

1) How do you make a link from inside a page on one SFW to this static server? If you make an ordinary [ link ] it opens as an external page.

2) This highlights the issue of plugin federation. For example, http://fed.wiki.org/view/welcome-visitors/sfw.thoughtstorms.info/homepage seems like it's working. But you won't see anything because I put all my paragraphs into a different type.

This seems a serious problem. Federation is in conflict with extensibility through plugins. What's the thinking about this?

a) some kind of graceful degradation (eg. unrecognised paragraphs are treated as paragraphs? or raw source-code is shown?)

b) Users are given the option to fork a local copy with an alternative paragraph type.

c) some mechanism for getting the plugin from the other wiki and installing it locally? (I recognise the security implications of this)

d) Asking the remote server to render the page as HTML?

[WardCunningham]

1) This video shows a variety of ways to link.

https://vimeo.com/36384739

The drag-and-drop (fragile for now) gets two sites connected. Then fork-on-edit spreads links throughout the reader's site-of-origin.

2) I'm thinking that inert content (json) will move through the federation faster than active plugins (javascript). Right now we leave it to site operators to install plugins that they have inspected and approved. GitHub clones of this site will be the preferred medium of exchange for now. (@nrn has a mod that links each site to its repo.) When you use custom javascript to render inert content you may have chosen the slow road to sharing.

2c) I would like to speed the distribution of plugins. I look to Caja or even more advanced security mechanisms to make this safe without having programmers checking the code each step along the way.

[nrn]

I'm not sure that it does everything we need it to, but I've had it in the back of my mind that https://github.com/substack/vm-browserify may work for running plugins we don't trust.

As for the static server thing my answer was to add the .json to the static files I was serving. I haven't updated it in a long time, but I was playing around with running a read only SFW based on github pages.

http://nrn.github.com, https://github.com/nrn/nrn.github.com

[WardCunningham]

At this point we've shown that a variety of static page read-only sites can interact well with federated wiki. With respect to ongoing development I suggest we continue our focus on the two server implementations we have.