Sven's curiosities

[SvenDowideit]

I don't know where directions, feelings and discussion are intended to happen (and I'm in Zurich til Jan'12 and then Brisbane again) so I'd like to share in the hope of getting some discussion & share

I have a number of ideas that playing with the code caused:

1. can we make everything a plugin 'item' in the emit-bind?
   • for eg, a page has a type, and contains story and journal typed items and so one?
   • in my first pull req, I called it title because I wanted to work towards an editable title (I noticed that someone has hand hacked the welcome-visitors page to have a non-linkable title) thus making it harder for a 'writer' to know how to link to it
2. can we make a group of topics - perhaps call it a book - in a sense, each server contains such a group, and the federation can merge&fork
3. I feel that the Local Edit functionality should be converted into a first class fork of pages that are on a/some servers - essentially, the Local Browser store is like a git clone working space, from which changes need to be pushed to either my server, or to someone else's
   • this means we need visualisation and merge UI's to facilitate
4. I'm going to ponder the idea that there can be different 'page' types / content - including a page that contains javascript code that is an item plugin - thus self hosting the code for the wiki, and allowing others to fork wiki applications (sorry, it really is obvious that I've been working on twiki/foswiki for the last 12 years)
5. docco! where the heck is the(actual&uptodate) docco?

Ward - am I taking this in a direction that might not be mergable / pluggable?

[WardCunningham]

Sven -- I'm thrilled that you've found the code provocative. I've found that most things I try to do are easier than I thought and then immediately suggest even cooler things to try. There are a number of smaller things that I've just left out because thinking them through hasn't been a priority.

For example, I've assumed that I would write a page title to slug converter soon enough (Welcome Visitors => welcome-visitors). In its absence I've just written slugs in links [[welcome-visitors]] instead of the more desirable title [[Welcome Visitors]]. (See commit and comments at 6332145b9979a8830c79547758a1b6eaaff1ea62) In the same way I've used HTML tags instead of markup, a practice that is very dangerous.

I've resisted making the system usable for creating content independent of the JSON underneath. Hacking the JSON directly is a good way to get a feel for what sort of things the software could do. I'm especially interested in having a lot less markup than wikis have right now, and maybe diverse markups based on item.type (say, a calculator markup, or even reinventing mathematics in ways suggested by "Kill Math".)

So, by all means, hack the code to try anything that comes to mind. Lean from coding. Find out what federated wiki wants to be. Please, share you discoveries here so we can all learn from your experiments.

And, open issues when you feel I should be working somewhere, or when you're about to work somewhere and want to know what I or others have been thinking. Healthy open source projects make important decisions in public. We'll get healthier as we practice this. Let's close this issue once we've taken all the points you've raised and created issues for each of them.

And, put up a server or two running any old code base that you think might federate. Change it often. Move pages back and forth. That is how we will learn what has to be held stable (and what doesn't) to keep a federation of servers vital. I'll make a list of interesting servers on this site's wiki. That can be our bootstrap until the federated wiki is complete enough to reliably host its own content.

Thanks for joining us. -- Ward

[WardCunningham]

The list of federated wiki pioneers appears here: https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki/List-of-Pioneers

[SvenDowideit]

I'm especially interested in having a lot less markup than wikis have right now, and maybe diverse markups based on item.type (say, a calculator markup, or even reinventing mathematics in ways suggested by "Kill Math".)

now that gives me an idea - I'll re-write the star list rendering as a seperate item. I also get the feeling that you're trying to force pages to be broken up, avoiding the double-return mess we have in existing wiki's.

which is another thing - atm, it breaks the writing flow to click 'add factory' rather than just hit return twice - so maybe I'll find a way to get the textarea to detect 'newParagraph' events.

the hard issue is how to allow the user to select a paragraph type - prose (what there is now), list (what I'll try out), etc.

[WardCunningham]

Here is an expense calculator I wrote 30 years ago.I was thinking it might make a good demo. Would have to translate AWK to CoffeeScript. Might be good to see the calculator work at the unix command line first.

http://c2.com/doc/expense/

[WardCunningham]

I'm going to close this issue under the assumption that Sven's Curiosities have been addressed. Just to be sure, I summarize as follows.

1. make everything plugged -- title is special because it generates url & db key. I'd like to have some Mediawiki automatic redirect on rename. About half the names in Wikipedia are redirects. The slug-making is first step. Thanks. Further discussion in new issue.
2. groups of pages as a forkable unit -- Interesting idea. We are certainly encouraging small pages. Acknowledge this as opportunity.
3. local storage just like another server -- Agree. Will do this when the fork-on-edit logic is undertaken. Right now the notion of remote is too incomplete to work on this now.
4. distributing code as content -- I'm hesitant to do this in that I'd like the JSON to be inert. A similar suggestion is that any story item of other than most familiar type (paragraph, image) should have a "git" parameter that cites an open-source plugin implementation.
5. documentation -- goals here are: (a) house-clean the wiki to be as-built plus roadmap for new developers (b) an interactive tutorial, maybe made by playing back an annotated journal.