We reflect on possible client-side models developed over a couple of hours of collaboration with Pete Hodgson. Here I record the CRC Cards we produced and will attempt to describe the dynamics we discussed.
This is only one possible end state, if there is even ever an end state. There remains order and completeness of implementation to be considered. We both favor an incremental approach. See Pete's post 
on "birthing" domain objects.
My later thoughts are in italics. Consider skipping these on first reading. Try pulling up rev 61.
Objects
Page. Provides the most portable representation of content and its history. A page can be translated to and from JSON without loss. A page is independent of the site that might host it while the interpretation of its content is not.
I think Pete wanted to add location to page but I resisted it. Hence the factoring of name and reference below.
Display Page. Supports viewing and editing. Look to these rather than dom objects to find visible story or journal elements.
A display page could be responsible for rendering unresolvable links in red. I decided not to have red links back when the only approach for resolving links involved probing remote sites for 404s.
Page Name. An immutable object that represents a resolvable name that can be interpreted throughout the federation. The double-square-bracket paragraph markup notes characters destine to be page names.
Page Reference. Refers to a specific page on a specific site in the federation. Could serve as the model behind a Reference plugin. A page name resolves to a page reference through a search within the resolution context. Undecided if a reference might optionally refer to a specific revision.
Resolution Context. An ordered list of sites that might host a page. Typically constructed from information that travels with a page. The exception is that the origin is often included.
Resolution context can vary from paragraph to paragraph. Among the Quirks of History context is now constructed while rendering and attached to links as title hover text.
Interpretation Context. Provides a scope within which many data retrieval operations take place. The arrangement of display pages implies one interpretation context but others can be constructed for more specialized evaluations. For example, the Rollup plugin evaluates Method plugins from pages that have not been displayed.
There is much that remains to think through as to how an interpretation shares responsibility with pages and plugins. The current ad-hoc approach does not offer much insight beyond showing that interpretation is possible.
Neighborhood. A collection of sites of interest as inferred by recent browsing behavior. A background process fills in details by retrieving a sitemap from each site.
A sitemap looks like a collection of page names. This was in the back of my head while we were discussing names. However, sitemap entries also include a synopsis which is both searched and displayed.
Scenarios
A display page includes a paragraph with an internal link. The resolution context does not lead to a page reference. A ghost page (?) reports the failure and offers to create the page. The ghost page includes page references from the neighborhood that share the page name.
A Radar plugin consults the interpretation context to find data to be displayed. Rearranging display pages causes the plugin to rebind to possibly different data.
A Method plugin binds to source data and then offers computed quantities that can themselves be bound by a Radar plugin.
A Rollup plugin consults one interpretation context to find page names which it resolves and retrieves. Then it constructs for each an alternative interpretation context within which Method plugins can be invisibly evaluated. See Rollup in Pseudocode.
See About Radar Plugin, About Method Plugin, and soon, About Rollup Plugin.
Sequencing
The Rollup plugin scenario brought up a number of questions regarding interpretations and their contexts.
We reviewed the use of tail-recursion in both the Rollup plugin and the Method plugin. Rollup created a bundle of statefull values which it passed to each Method for safe keeping while it managed its own state in a similar way.
We spiked a implementation of a Simple Promise and showed that it could sequence a calculation without tail-recursion.
Kris Kowal has been quietly developing awesome functional javascript for years. Pete recommends his promise implementation called Q. See github .
jQuery has an acceptable implementation of promises since version 1.5 (about two years). doc . Eric Hynds wrote the often cited post about it. SFW contributor Steve Black is mentioned as editor.
.
It became hard to find time to work with Pete once he became a father. I notice this page is six years old. No surprise that the kid is that old too. twitter