How to connect Apparatus and wiki? I find myself stalled in this question. Here, I write to think as a first tiny step. Can I build some momentum?
See Up and Down the Ladder of Abstraction 
. Combining wiki with apparatus would empower similar "writing." But this writing will defy or what we mean by publishing. Or force its redefinition.
I containerized apparatus for use in a local installation: Container dobbs/apparatus. I have also made it easier to add virtual hosts to Container dobbs/proxy.
* [x] publish apparatus container to apparatus.wiki.dbbs.co
* [ ] tell a story in wiki about publishing apparatus
* [ ] upload TickTock.json and tell a story about it Publishing TickTock
I sketched an apparatus viewer plugin. That could situate a diagram within wiki; allow for diagrams to be surrounded with prose. Forking such a page would depend on installing the viewer plugin on the remote wiki. Plugmatic would help there, once the plugin were published in npm. But the diagram would remain in my containerized server.
Provided the wiki container and the apparatus container can share a docker volume, then perhaps careful naming could allow the page to carry the diagram with it. But that would impose more than forking on the admin of another wiki.
Apparatus is all coffeescript, statically compiled for use in the browser. Should therefore be small-ish effort to put all of it in a plugin. No external container required. Perhaps that's phase two in a plugin development roadmap. But how to manage the interaction? Double-click on a diagram opens the editor full screen? One can foresee conflicts between two code bases listening for drag events.
Do I hack apparatus to save diagrams in wiki?
Do I expose apparatus variables to radar plugins?
Do I instrument apparatus so detect wiki radar data?
Which of these seeds to plant?
ward
All good ideas. Running apparatus in the wiki-client address space would seem the big win for interesting integrations. Map is a good example. It can look for other markers and set bounds accordingly. Scrolling isn't an action and won't be saved. But planting a new marker is and can be undone by forking earlier revisions.
A good approach might be hacking one example (maybe the wheel) and making it an interactive viewer like the map. If the apparatus codebase yields to this then we can consider how authoring might work.
We're always looking for ways that authoring can be shared between different authors on different sites. Mix and match features? What would that be like?
An interesting warm up might be to build a plugin that could run a couple of examples from g9. Authoring is left to javascript in g9 so that looks less attractive from a secure sharing point of view. But the viewer interactions are awesome and might factor out in ways we can't imagine. See Solve for Initial Conditions