It is important that a data wiki can do calculations. I offer my expense calculator, a 20-line awk script, as a model for the simplest calculator that could possibly work.

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

A good strategy would be to first duplicate the awk script's functionality. Then it might be interesting to generalize the built-in functions to do general data wrangling while looking to the left for data and offering results up to visualizations that appear on the right.

We now have the location bar (and the history behind it) updating when we open internal links. But we don't refresh the screen when we go backwards through that history. That is, when a second page is added to the screen, the back button should revert to the single page that existed before the second page was added.

Also, the local editing option could now reinterpret the current position in history based on the strategy for finding pages. This probably isn't how local storage should ultimately be handled but it might be a step in that direction?

When we follow a link to a non-existant page (a red-link in wikipedia terminology) the Sinatra version of the server makes a new page on the spot. This should really be handled in the client code in response to a 404. This has several advantages:

• This is the expected server behavior when serving static pages
• The client can make a better page because it knows more, such as the non-slug version of the title.
• The client can defer persisting the page until it is edited. (The server had to persist the page so it could remember generated IDs).
• The UI experience might be improved by doing something other than generating an empty page.
• The client could mark the link as non-existant (red-link), something we haven't asked the server to do when serving pages.

Ctrl-S is less than ideal for saving entered text as it opens the "save this web page" dialog in Linux/Ubuntu.

Any reason we're just not using a button? It's just as easy to save from the keyboard as you just press tab then enter.

server / sinatra / views contains template definition data on how to render.

This is currently used by the node.js (html) and sinatra (haml) servers and by the static server .htaccess setup (html).

Also, my moving that into the data dir, we're allowing local customisations, which I'm also interested in.

I have mentioned a number of times in other issues and in the hangout that I want to improve our experience on mobile devices. I would like to propose writing a second, touch-oriented client. We already have multiple servers speaking the same API, so we should be able to also write separate clients.

I would like to gather desiderata and technical suggestions before beginning, but obviously we will consider this just an experiment until we have something compelling to actually show.

Goals

• Create a consistent and extensible set of UI patterns that are optimized for touch surfaces like phones and tablets. These devices do not have hover states, need larger click targets, and cannot distinguish between dragging and scrolling. Different types of servers, stories, and plugins need to be able to hook into these patterns to expose extra information or actions, that will then be presented appropriately to different types of devices.
• Rewrite the client code in terms of a server-facing model layer and a user-facing interface layer. The model layer should be bootable in a scripting environment like node.js to make it easy to import data to the server or write bots that automatically change or edit data. The user-facing layer should work well across typesof devices, and allow the model layer to not worry about the type of device the site is being displayed on.

Implementation

• Use a front-end MVC library like Backbone or Spine rather than storing so much information in the dom.
• Use localStorage and the html5 apps apis to make the wiki work offline, have a home screen icon, etc. to fit better in the mobile environment.
• Coffeescript, of course.
• Need to think about load-time performance as the amount of front-end code increases. That means either asynchronously loading modules or else combining and minifying all the code together.

Roadmap

I am suggesting the following roadmap for integrating this client as first an experiment, eventually an alternative, and eventually perhaps the default client for SFW:

1. Create a basic implementation in a touch-client folder in the main project.
2. Alter the ruby implementation of the server to serve the touch client javascript when accessed with urls that use "touch" instead of "view."
3. Implement basic page and plugin rendering with the new client so we can play around with it.
4. Add conventions for editing that work across multiple device types one by one

Design

I am brainstorming a design that will use the same conventions, but with appropriate differences, for different device types. Right now my thoughts center on using little "handles," such as Appleuses in the iPhone/iPad versions of Numbers.

Each page and each plugin within it would have a little handle, that could be activated to expose edit actions on it.

I would love to hear everyone's thoughts and comments.

So it's past time to write some tests for the express server, but i'm having trouble deciding on what testing framework to use. I've been looking at a variety of things, including mocha, node-tap, vows, and jasmine, but I really don't have enough experience with testing to make a decision. Does anyone have any thoughts, either on specific test libraries for node, or considerations when choosing one?

I wrote a JS fuzzymatching library for a GTD app I'm building. I'm using it to power an autocomplete widget for quickly jumping between places within the app.

I've been following (and learning from) this project with interest for awhile and am interested in helping out if I can. If there's interest, it'd be pretty easy to wire up an autocomplete widget that searches across all loaded pages.

You can see a demo of the library at http://kyleamathews.github.com/Fuzzymatcher.js/

How do you build a link to a federated site?

Is there a special link syntax I should use??

tx, Andy

The plugin api evolved to solve one not-to-interesting problem: distinguishing startup code required for static(html) and dynamic(json) wiki pages. Weaknesses have emerged:

• some doubt the utility of static html -- we preserve it mostly for seo
• a carelessly assembled collections of utilities have emerged in the wiki object
• the api has been converted to one using callbacks to deal with issues loading dependencies
• story item types with text have to repeat the binding of the textEditor

We've also bastardized the plugin/factory interface to suggest how factories might work

• the factory plugin has been split into a meta-factory which is converted to a factory plugin by the server
• the server inserts a plugin menu as part of this conversion
• the conversion menu has been hardwired since it is not easy for the server to tell what plugins it hosts
• the drop handling in the factory plugin could delegate some case analysis to plugins
• it is left as an exercise for the site owner to figure out how to add new plugins

Finally, Adam points out that plugins know way too much about how the mouse works to make it work well with touch.

• #100 (comment)

He goes on to say, "The net step, it seems to me, will be to rewrite the way editing works. Because the current plugin implementations are not ideal for touch-based clients, I would like to suggest that we rewrite them but I'm not sure how much opposition there is to that idea. Specifically, instead of allowing plugins to arbitrarily bind events, I'd like to expose a handful of hooks they can use (to specify different allowed user actions) and that way we can have a single implementation for how those actions are displayed in the UI. That way we can change the UI in one place and have all plugins change to match."

In this issue I'd like to hear some suggestions as to a good path forward. Hopefully we can continue to work in smallish increments.

I am looking for suggestions and advice about an idea I had for adjusting the client-side code.

My goal is to refactor the current client coffeescript code, which uses the dom to implicitly create the Miller Column metaphor, and explicitly model the columns and their state with a new idea: a Path. A Path is simply the current set of stories you are reading and their order.

I think this is a natural direction for the software to grow, and allows a number of easy developments:

• The client code could save your current Path and let you pick up from the same place when you return later.
• You could send a link to a friend that captures not just one story, but the current Path of stories you are refactoring.

I would appreciate your thoughts before I begin.

as @stephenjudkins express based one surpasses it.

(and sweet :) )

I'm working on a round of cleaning up and package management stuff for the express server now that I think it's to sort of an alpha usability level. I'm making it available for global install, and i'm thinking about the best way to publish it to the npm repository, which means I new two new single word names. I'd like to propose sfw-noded for the command that goes in path, and sfwiki for the npm/node require name. This would mean that the entire process of getting a server up and running on a computer with node installed would be two commands:
npm install -g sfwiki
sfw-noded

Is this something we want to do? If so I've got to solve the problem that npm expects the package.json to be at the top level of the thing to be installed, which doesn't lend itself well to how we are organized. One possible way to solve that is by using symbolic links out from the servers to all of the shared files they include. I believe git supports this, but it may be a problem for developers on old (widows xp?) platforms. The git repo would stay organized in the same way, but the servers would access the files as if they were inside their own server/servername folder, so any server could be packaged up as it's own thing with the client for deployment.

In the comments for pull request 98, Ward mentioned:

Nick is looking to rename "server/express/bin/server". Is there a problem with that name? The name "sfw-express" seems to encode information already present in the path to the file.

Seems to me, following typical web server naming idioms, the server should be named "#{thing-it-serves}d". So sfwd would be the name.

Or perhaps since there are two servers, it should be called one of:

• sfwd-express
• sfw-expressd
• ???

I think I like that first one. When the day comes when there is a single reference server, we can rename whichever that is to sfwd

Also, we should look at adding a bin entry to the package.json, so that when folks do an npm -g install, it will install the binary in a nice place. See, for example, https://github.com/jashkenas/coffee-script/blob/master/package.json

I'm able to view pages on it, but neither double tap or single tap do anything.

if its something else, then perhaps that needs docco :)

needs a Readme for thos of us that don't have an Arduino environment to play with telling us how we would test changes / compile / install

and (the important bit for me atm) what limitations / differences there are to the reference server.
(I have to write the same for the node.js work in progress)

(while I'm in Zurich, I can't even 'borrow' Pam's Arduino :) )

In working on the express server I found a minor bug in client.coffee data.journal should be page.journal, which I fixed, compiled, tested and then went to commit, which brings me to the issue:

The compiled client.js seems to be equivalent on my machine, but fairly different in actual text. So what's the procedure for this? Do we not care about client.js battling back and forth and assume it will trend towards the newest version? Or is there a specific version of coffeescript that I should be using?

Using Chrome, the command-r command (reload this page) will reload an unedited copy of the page from cache rather than reloading the edited copy from the server.

Solution: somehow flush the cache for json files when the copy on the server has been edited.

Work-around: a second command-r will ignore the cached version.

I have not tested other browsers. Perhaps the behavior there will require a shift-command-r to ignore the cache for the work-around.

The implementation of this wiki would be easier to follow if the word article were used in place of almost every reference to page. Although the original wiki spoke of pages, Wikipedia prefers the more accurate term, article. For good reason. Article refers to the creative work, page refers to a medium upon which it might be delivered. Since we deliver multiple articles on a single web page, this misuse of terms is especially confusing. See also:

• Article-Page Pattern
• http://en.wikipedia.org/wiki/Article_(publishing)

I suggest wholesale replacement of the one term with the other in our code, in the file hierarchy and in our ongoing conversation.

I am using Firefox 9.0.1 on mac running Lion and I am unable to vertically scroll the miller columns.

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?

if you move all the items out of a page, and then re-start / reload that page, you'll get a haml crash

/home/sven/src/Smallest-Federated-Wiki/server/views/page.haml in evaluate_source
            %div{:class => ['item', type=item['type']], :id => item['id'], "data-static-item" => item.to_json}
/home/sven/src/Smallest-Federated-Wiki/server/views/page.haml in each
        - page['story'].each do |item|
/home/sven/src/Smallest-Federated-Wiki/server/views/page.haml in evaluate_source
        - page['story'].each do |item|
/home/sven/src/Smallest-Federated-Wiki/server/server.rb in GET /
    haml :page, :locals => { :page => get_page($identity['root']), :page_name => $identity['root'] }

poking around a little, it seems that we serialise an empty story in the json as story: [null]] whereas

removing the null fixes the crash - I presume that an empty array is a simpler way to denote empty?

Turns out it's pretty easy to do a gradient favicon in svg:

 <svg width="16" height="16" xmlns="http://www.w3.org/2000/svg">
 <!-- Created with SVG-edit - http://svg-edit.googlecode.com/ -->
 <defs>
  <linearGradient y2="1" x2="1" y1="0" x1="0" id="favicon">
   <stop stop-color="#ff0000" offset="0"/>
   <stop stop-color="#ffff00" offset="1"/>
  </linearGradient>
 </defs>
 <g>
  <title>Smallest-Federated-Wiki favicon</title>
  <rect id="svg_1" height="16" width="16" y="0" x="0" stroke="#7f0000" fill="url(#favicon)"/>
 </g>
</svg>

It would mean no canvas library needed. Just use same random color code tied to a templatized version of above.

Only downside is doesn't work in all browsers for true tab favicon, but that seems minor since it works on wiki pages.

Course some sort of pluggable system would be ideal for png, gravatar, svg, etc.

Thoughts?

~/Smallest-Federated-Wiki/server/sinatra$ bundle exec rackup -s thin -p 1111
/home/me/.rvm/gems/ruby-1.9.2-p290@sfw/gems/RubyInline-3.11.0/lib/inline.rb:865:in `stat': Permission denied -      /home/me/.ruby_inline/ruby-1.9.1 (Errno::EACCES)

Hoped some of you here might have some clues about the above error when trying to start server? Installed Ruby version via rvm on Ubuntu 11.10

Currently, the express server depends on the user having coffee-script already installed on their system. It's far easier to just include coffee-script as an npm dependency, and use it that way.

Making this change also requires bin/server to change to be js, and not coffee, and then some reorganization of the code that used to be in bin/server

So I have favicon generation up and running on the express server, but it comes with a pretty harsh dependency that requires cairo on the server. The generator is in coffee script and uses a canvas like api, so it should be pretty straightforward to get it working in the browser, so that if the client gets a 404 on the favicon it can download it, generate it's own and then try and put it to the server. Is there any interest in this? Or should we keep it as a server side thing, and i'll look for a lighter way to generate them in node?

--nick

I haven't tracked down the exact mechanism yet but somehow the client gets confused and decides to make a new server-side page where one exists already. Some possibilities:

• something temporary went wrong server-side, client mis-interpreted the error code as 404
• some interaction with history: no smoking gun yet
• no server-side check for existing page when handling the create action -- fixed c11c2f7

All these need some attention. I've been batch building sites and haven't lost any irreplaceable work yet, but it is only a matter of time unless all these possibilities are explored. (Add your own thought about power and responsibility.)

I'm bothered that I'm GETing /welcome-visitors.json, but PUTing /page/welcome-visitors/action.

given that I'd like to do other base level datum types, and make pages be prose wiki, and that an .json extension should really not happen (in REST world) - content negotiation?..

Can we change the GET page source to be /page/pagename ? and remove the redundant /action from the end of the PUT's?

Hello,

I'm having some problems with the installation. I'm using Mac OSX 10.6.8 with XCode 3.2.5 (so Ruby 1.8.x without Rail, etc). I upgraded to Ruby 1.9.2-p290, loaded Rails, etc, but am getting stuck when trying to load one of the require gems - diff-lcs. See below:

Abacaxi:Smallest-Federated-Wiki m3rabb$ bundle exec rackup -s thin -p 1111
Could not find diff-lcs-1.1.2 in any of the sources
Abacaxi:Smallest-Federated-Wiki m3rabb$ gem install diff-lcs
Fetching: diff-lcs-1.1.3.gem (100%)
Successfully installed diff-lcs-1.1.3
1 gem installed
Installing ri documentation for diff-lcs-1.1.3...
Installing RDoc documentation for diff-lcs-1.1.3...
Abacaxi:Smallest-Federated-Wiki m3rabb$ bundle exec rackup -s thin -p 1111
Could not find diff-lcs-1.1.2 in any of the sources

The gem installer is loading version 1.1.3 but seems to be demanding version 1.1.2 instead. I would appreciate some advice on how to get past this problem.

Also, perhaps you might want to consider to doing an install of the wiki from a relatively ruby-virgin machine like mine. The current instructions could be improved by mentioning loading the rails, the missing gems, etc.

Looking forward to using it!

Thanks,

Maurice

A natural way to add a new site to the federation is by citing content on that site in the form of bibliographic references. It is my intention to add a new story item type and corresponding plugin to the set of basic types. I imagine this will include reference specific fields for things like title, favicon, and text annotations. One server could keep track of other servers by recording remote page size, date of last update, observed update frequency, and so on. I can assume that travelers through the federation will find pages worth forking by reading bibliographies assembled by others.

• Wikipedia notes: Webography or webliography are bibliographies of websites. The first use of the word "webliography" recorded in the Oxford English Dictionary dates from June 1995.

I have refactored the factory drag-and-drop code to make it easier to add new drop subjects. The html5 api is notorious for its complexity but dropping links from a browser's location bar of reading links from desktop weblocs both seem doable.

• https://developer.mozilla.org/En/DragDrop/Recommended_Drag_Types#Dragging_Links

I'm assuming it is possible to recognize when a server is serving federation compatible content. I suggest simply following a dropped link and look for JSON content that meets federation format. I would check for a title that is a string, a story that is an array, and an optional journal that its also an array. Further, I could check that the story items have types and ids and that the journal actions have types drawn from a familiar set (add, remove, move, edit).

It might be reasonable to expect all sites to offer a bibliography of valued sites much like bloggers enumerating their blogroll.

I just found my arduino mega, and started to think about buying some sensors, so I read a little of the code, and decided that it would make sense to document what sensors you have attached to which ports on what hardware.

I'm guessing there must be a nice way for us to move the ip, ethernet and port settings out of the code, but that can wait until I actually have something.

Sven

The second .replace on Line 8, https://github.com/WardCunningham/Smallest-Federated-Wiki/blob/master/client/client.coffee#L8 should use parenthesis for consistency.

Problem: Journal "hover" highlight effect only works after an Edit

Reproduce: Load any page with div.journal>span items. Hover over the div.journal>span items.

Observe: No story highlighting (yellow background) is displayed around the appropriate element.

Expected: Story highlighting (yellow background) should be evident.

Continue: Edit a paragraph. Save changes. Hover over the div.journal>span items.

Observe: Story highlighting (yellow background) is evident.

this might be in the express server, as I did it to @nrn's site :)

Make a label element for the "Local editing" checkbox.

Problem: Duplicate "edit" class applied to edit spans in the journal div.

Reproduce: 'View source' on any wiki page with an edit "e" displayed in the journal

Observe: this string in div.journal

 <span class='edit edit' ...>

Expected: Just one "edit" in the class attribute

 <span class='edit' ...>

Source of the error: Line 23 in page.haml
https://github.com/WardCunningham/Smallest-Federated-Wiki/blob/master/server/views/page.haml#L23

I'd like to invite coders on this project to join me on a weekly google video hangout. I will make a point to be online there at 10am pacific time (utc -8) most wednesday mornings.

• https://plus.google.com/hangouts/_/extras/talk.google.com/fedwiki (obsolete, no replacement)

As I understand the hangout documentation I can invite a circle of up to 10 people and they will get special notices when the hangout starts. If you would like to be in that circle, send me email with your google id so I can add you to that circle.

It is my intention to use google hangouts hear issues with, and ambitions for, this project. However the discussions of record will remain here on GitHub.

should not be hard either.

Now that we can claim servers (with OpenID) it is time to make Local Storage in the browser work like a server you've already claimed. This works ok already since we've made editing a claimed site (without login) equivalent to checking the old Local Storage checkbox.

Local Storage is the storage new users will use until they setup servers of their own. Let's help them understand where their edits are going and help them move their edits where they want them when they finally decide where that is. New users will confront two mysteries:

• I've just edited a federated wiki page and the page turned yellow. What could that possibly mean? What happened to my edit? Who can see my change? Can I undo it?
• I've been making edits on several federated wiki sites. Now I want to share these changes on the internet as my own. How can I collect these changes and put them up on some new server? How do I get a server? What steps do I follow to move my Local Storage pages there?

I'm going to suggest two big changes that could be two or more issues in their own right. I will describe them here in order to have a high-level discussion. I'll probably have a go at both of these issues soon enough and it I can't get it done I will write the more specific issues. For now, the two big changes are as follows:

• Model both the origin server and Local Storage as storage devices with a unified API captured as model objects on the client-side. Most of this organization will be invisible to the end user. However, local storage should have its own generated favicon and something useful should happen should the user click it. The favicon for Local Storage should suggest the origin servers favicon modified in some predictable and describable way. I suggest overlaying a cross-hatch pattern over the origin favicon. (See http://stackoverflow.com/questions/8337570/best-way-to-mask-an-image-in-html5)
• Provide a whole-site storage format (in JSON) for moving pages between sites. Add a special page to each server that describes how to move Local Storage pages and offer a 'data' story item that holds all Local Storage pages in that JSON format. (Note: this has to be a client-side mechanism because Local Storage is client side. I'm guessing some "data url" trickery can get local storage into the JSON preview window where they (or any other JSON) can be stored to the user's local file system. This means that a user can get a hold of his own pages. Another challenge would be to take a handfull of these sorts of files and upload them in bulk to a brand-new server.

We can talk about a new-user funnel that will lead to a critical-mass of federated wiki users. That funnel works something like this:

• user finds a federated wiki page
• user groks that federated wiki is something special
• user tries editing, finds that it just works
• user starts curating pages that are personally valuable
• user learns that existing edits can be moved to a public server
• user moves some edits to a public server, likes the result
• user moves remaining local edits to one or more public servers
• user becomes advocate of federated wiki

None of these are big steps. But its time to make sure this path has the minimum of friction.

The proof-of-concept currently uses jQuery 1.5.1. It's probably a good idea to stay abreast with jQuery.latest until release, and beyond.

sorry, I just havn't worked out how I can reference a topic 'elsewhere', and how to click 'fork'

this makes me sad :)

The README.md of the Wikiduino server is out of sync. Two files are mentioned i.e.

• Wikiduino.pde
• Wikiduino.ino

But only the Wikduino.ino is present.

Currently local changes to /data/status/local-identity get clobbered, or require a merge, whenever we git-pull.

I checked the Local editing box. Moved some stuff around. Then unchecked. When I first moved stuff again I get the following:

NoMethodError - undefined method `[]' for nil:NilClass:
 /home/gweber/proj/campus/Smallest-Federated-Wiki/server/server.rb:73:in `block (3 levels) in <class:Controller>'
 /home/gweber/proj/campus/Smallest-Federated-Wiki/server/server.rb:73:in `each'
 /home/gweber/proj/campus/Smallest-Federated-Wiki/server/server.rb:73:in `detect'
 /home/gweber/proj/campus/Smallest-Federated-Wiki/server/server.rb:73:in `block (2 levels) in <class:Controller>'
 /home/gweber/proj/campus/Smallest-Federated-Wiki/server/server.rb:73:in `collect'
 /home/gweber/proj/campus/Smallest-Federated-Wiki/server/server.rb:73:in `block in <class:Controller>'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:1151:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:1151:in `block in compile!'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:724:in `instance_eval'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:724:in `route_eval'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:708:in `block (2 levels) in route!'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:758:in `block in process_route'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:755:in `catch'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:755:in `process_route'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:707:in `block in route!'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:706:in `each'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:706:in `route!'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:843:in `dispatch!'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:644:in `block in call!'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `instance_eval'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `block in invoke'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `catch'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:808:in `invoke'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:644:in `call!'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:629:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/head.rb:9:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/showexceptions.rb:21:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:1272:in `block in call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:1303:in `synchronize'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/sinatra-1.2.6/lib/sinatra/base.rb:1272:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/urlmap.rb:52:in `block in call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/urlmap.rb:46:in `each'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/urlmap.rb:46:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/lint.rb:48:in `_call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/lint.rb:36:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/showexceptions.rb:24:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/commonlogger.rb:20:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/chunked.rb:41:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/content_length.rb:14:in `call'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/thin-1.2.11/lib/thin/connection.rb:84:in `block in pre_process'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/thin-1.2.11/lib/thin/connection.rb:82:in `catch'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/thin-1.2.11/lib/thin/connection.rb:82:in `pre_process'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/thin-1.2.11/lib/thin/connection.rb:57:in `process'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/thin-1.2.11/lib/thin/connection.rb:42:in `receive_data'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/thin-1.2.11/lib/thin/backends/base.rb:61:in `start'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/thin-1.2.11/lib/thin/server.rb:159:in `start'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/handler/thin.rb:13:in `run'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/server.rb:265:in `start'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/lib/rack/server.rb:137:in `start'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/gems/rack-1.3.2/bin/rackup:4:in `<top (required)>'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/bin/rackup:19:in `load'
 /home/gweber/.rvm/gems/ruby-1.9.2-p290/bin/rackup:19:in `<main>'
127.0.0.1 - - [29/Sep/2011 03:38:26] "PUT /page/smallest-federated-wiki/action HTTP/1.1" 500 5222 0.0019

I mentioned this on the pull request, but I think it deserves it's own day in the sun:

http://nickn.github.com

http://nickn.github.com/view/welcome-visitors/view/indie-web-camp/view/why-indie-web

https://github.com/nickn/nickn.github.com

This is up temporarily as an example of how we could use the clients new ability to read it's own page list from the url to self host the projects page using gh-pages. It uses two static html files, index.html and 404.html, so that any request to the root folder gets index.html returned which includes the welcome-visitors page div, and any other arbitrary page url returns 404.html, which then reads the url and loads the appropriate json. It is a bit of a mess, having all the pages and info placed according to how the server expects to find them, but with no htaccess file or any other way to redirect urls, it's still possible to have a fully functioning read only SFW served.

The general work flow seems that it would be to have a local wiki on your machine that you edit to your hearts content, and a build script in the gh-pages repo that copies the pages over, adding .json to the end, as well as the javascript version of client.js and plugins, and then pushes it up to gh. Or something along those lines.

If you're interested I think this could be very nice way to do the video page, giving people a hands on read only example of what you are talking about while they watch.

--nick

I'd like to upgrade some of the information we capture as we make and edit pages. I've been hesitant to add things because it might be useful so I will suggest exactly what I'd like to see done with the extra information.

• Use a well-known uuid format for paragraph ids. http://en.wikipedia.org/wiki/Globally_unique_identifier. I'm struggling a little knowing what I get for this but I've hesitated calling id a uuid when I've made no attempt to format them as such. I suggest we use what ever we find but generate the documented "random" format. This would still be called "id".
• Add a sequence number to journal actions. These would be assigned at the point where actions first enter the journal. In normal operation that would be on the server side. With local storage it would be local. Where a back job directly updates files, I'm not sure. Right now the batch jobs I've written don't add journal actions in this case. This would be called "seq" as it is in CouchDB.
• Add a timestamp to actions. I suggest adding this at the time the action is first formed, usually on the client side in response to some user operation. Milliseconds since the epoch would seem to be the right javascript thing to use. I would use this to enhance the user experience but not otherwise change the behavior of the system. Examples would be saying "3 days ago" when hovering over an action or collating actions for all pages into a "Recent Changes" report. This would be called "date".

Double clicking on the Factory block does not start editing that paragraph. Tried it in firefox and chrome.

When the server is down the client will happily follow links. Because no data is retrieved it will render an empty page with a page title.

It should be possible to provide an informative message to the user that the server is not responding.