diff --git a/README.md b/README.md
index f395ff5d8206e6e89119391af4986ee7046783dc..fb6bcf4d23e22f112c9bd815f9161c031e69a5b8 100644
--- a/README.md
+++ b/README.md
@@ -1,106 +1,94 @@
-# Hello DMCC Browser
+# Cuttlefish
-Find fun pet name? RuNDMC stays? Reconfigure, Use and Navigate Dataflow Machine Controllers.
+Nautilus is a **[Distributed Dataflow Machine Control Context](https://gitlab.cba.mit.edu/jakeread/ddmc)** for the browser.
-# The Dataflow Development Environment
+It's unique to these contexts - it's (so far) the only one that draws graphs, and gives us handles on manipulating them. Cuttlefish is an 'Integrated Development and Operation Environment' or something - an IDOE (?) / IDDE: an 'Integrated Dataflow Development Environment'.
-An IDDE: Integrated Dataflow Development Environment.
+It's main job is to provide views (see hunks/hidden/view.js) into other controllers' brains, and help you compose those brains, hook them up to eachother, and make sense of big sprawling programs as one big pile of delicious messaging spaghetti.
-Our dev environment is itself a context having hunks and a manager... We're not so much writing programs as we are scoping into contexts and sending messages: add this, connect these...
+Native Cuttlefish 'Hunks' can write to the DOM elements they are attached to, so we can use it to compose machine interfaces as well.
-Loading / saving programs we can do locally for remote resources. So long as our mutual understandings don't change (a thing called 'this' does 'that', has 'these' and 'those' outputs etc).
+For more info on the Distributed Dataflow Machine Control project, please [go to this page.](https://gitlab.cba.mit.edu/jakeread/ddmc)
-## To Start
+## Notes
-I'm going to re-write the browser to have its own DMCC Manager.
+Today I'm combing through my very rough notes taken while I wrote this thing. I take for granted that it's not done yet, but in the effort of spiraling through writing... Here are some synopsis that I should not forget are things-worth-mentioning.
-The browser is going to display, using most of the same code, hunks and links from multiple different contexts, by piping its fingers through whatever link it wants.
+### Views are Hunks, Too
-One of these managers is 'Native' ...
+An important aspect was that the 'View' (because we can have many of them) is also a 'Hunk' - this was at times confusing when writing the 'native' 'manager' for the browser, but is going to be a real watershed when I start opening offworld contexts up. This way nothing is mysterious - views aren't mystery windows into other worlds, they are software objects whose messages are obviously routed through the framework.
-so ... ui sends messages ... to whichever manager. to start, it's its own manager
+```
+The UI participates in the computation: anything a user does needs also to be flow-controlled, passed as a message, etc.
+```
-## Context Switching
+
-I'm figuring the browser (to start) has a dropdown menu, where you can poke through links that are displayed, and set them as the browser ports? Like, the view 'ports' ... ? Some handle that the browser can pipe events into, and handle responses from.
+This means (as I hope I will see) I can route many views through many contexts, although the view(s) are still obviously (as they are) hunks that operate in the cuttlefish context only.
-## Navigating
+
-This problem is tricky.
+This still annealing, but I like the direction. It's a tricky pickle, and really at the heart of this problem. Singular views into many programs running together, at once.
-## UI is a hunk as well, can post messages to managers, and receive them.
+### State in the DOM; use JQuery & Unique Human-Readable IDs
-It draws things based on these messages...
+A big windfall for implementation was my adoption of JQuery and DOM-element-id-writing for selection, etc. This makes programming kind of 'conversational' ... I think most web developers know this, but now I do to. This lets me avoid keeping some global state objects, instead just inspecting the DOM every time something happens and checking it for consistency against messages I receive from the manager.
-UI is hefty, and all knowing, but at mercy to the manager for execution, and it has a loop f'n. Many fingered.
+### Give Up on Storing Position
-At the core of the browser-does-dmc business is this misalignment between the browser world of callbacks-and-event-catching and message passing.
+TBD, but I'm going to try to adopt a policy of live-positioning everything. [D3](https://d3js.org/) has a great, straightforward force-layout scheme... I can use this to load graphs and draw them in 2D space (actual dimensionality: ?) without having to write those positions into the program representations, where they are meaningless unless rendered.
--> at the moment, rewriting port reps, dom 'def' handling
--> towards saying hello to an in context element(s) and manager
+### CSS Transforms are a PITA
--> then we want to abstract messages, links, etc ... and pick contexts for right-clicking, and have heirarchichal dom handling
+I spent a good deal of time struggling with scaling and panning views. I'm not sure that I learned anything, and while I couldn't find it at the time, I think I have figured out a simple way to alleviate my pain on this front. I'll leave this note for myself here: div(div).
-- get up to bower loading things today
-- write one module having buttons
-- write one module having canvas, loading svg
-- write the logger module
-- consider a state change
+### JS Promises are Great
-- managers ... and contexts ... and links ... the crux
-- consider your UI drawing as a member, a hunk, having links to links ... having each UI context also heirarchichally rep'd ... this makes lots of sense
- - req for load does not callback, it's a message
- - same with state change
- - same with module adds ... reflect this
+For async module loading, etc. Do use. Herringbones nicely with event graph model and is a helpful model when considering how message interperetation should work (i.e. forces / reminds me to consider message reception as async).
-- roll manager back into node
+### Contextual Messaging / Heirarchichal Messaging
-## Cuttlefish / Lilith
+This is something I'm still very much working through -
-OK, I want to make clear what-all I'm planning on doing here.
+'messages are graphs too' is floating around. I'm still trying to narrow down the set-of-messages that a manager should be able to react to. To start, most routing is just program organization. In some instances things will be contextual though, and are implemented as such: for example, I'm looking forward to implementing (in cpp) on microcontrollers a manager that lists 'available hunks' in relationship to which (limited) microcontroller hardware resources are not already initialized in the graph.
-The browser participates in the computation: anything a user does needs also to be flow-controlled, passed as a message, etc.
+In another context, to allow managers / contexts to grow features without having to add them 'across the board' (for example: I'm probably going to want an idea of graph execution priority in the micro, but not in js), I can use a call-and-response type of message tree traversal. For example, from the manager:
-So, we set the UI up as a Hunk within a top-level manager, and set it next to another Manager. So, at the get-go, we already have two managers, nested. The UI element is initially hooked up to our one-and-only manager to begin with... It gets its own DOM in the browser.
+```JavaScript
+ this.replyHello = () => {
+ // writeMessage does buffering on our end
+ let options = [{
+ text: 'list available hunks',
+ header: 'listhunks',
+ content: ' '
+ },
+ {
+ text: 'describe running program',
+ header: 'listprogram',
+ content: ' '
+ },
+ {
+ text: 'save running program',
+ header: 'saveprogram',
+ content: ' '
+ }
+ ]
+ this.writemessage('putcontextoptions', options)
+ }
+```
-The UI hunk won't ever see that toplevel manager.
+The 'view' doesn't have a baked in set of 'right-click options' - on a right click it basically just waves at the manager - the manager can decide to send back what-all are the possible options given its state. This is some kind of conversational programming...
-the native manager contains other managers,
-one of which has access to the dom (the first)
-the native view contains all other views
-
- view -> | -> nativemanager
-view -> | -> anothermanager
- ... etc,
- ... at the top level is this manager running two hunks, one a view, one the native manager... probably the yin, the yang, and peace in all the kingdoms
-
- -> tree message (stateful)
- -> or std message, others:
- -> add link
- -> ... ? these are also outside of tree
-
-### f
-
-A view is an object that has (1) a path to a manager, and (2) a dom. This is simple enough, however, views can also spawn and contain other views.
-
-**To start in simple time, I'm going to write a view object, give it a dom and a messaging port to a manager. When we spawn a new manager, I'll have links, and answers.**
-
-View doms are related to one another in a way that is similar to how messages are routed to their managers. These are mirrored trees. They mirror about ... the ... link ?
-
-This feels strange. That's because the views are also hunks that run in a manager. Inside of our view, we have to have some nesting, the same as our managers are. Views need loop() functions, and to be able to add views... to have a list of views. OK.
-
-Let's get to that heirarchy.
-
-### Message Statemachine Trees
+Also consider: the 'fog of war' but for these graphs. The notion of graph traversal doesn't exactly reconcile with another idea about stateless message adoption... but we can pass entire graphs each time.
hello ->
- <- available branches (bytes: names)
+ <- available branches (bytes: names)
branch ->
- <- response (branches or action) ... ?
+ <- response (branches or action) ... ?
branch ->
- <- response (branches or action)
+ <- response (branches or action)
action ->
- <- confirm, new status
+ <- confirm, new status
Messages:
@@ -110,183 +98,9 @@ Messages:
- request to add this thing (hunk or program)
- request to link these things (outputs to inputs)
-### OK
-
-I'm getting a bit tired of this. I'd like to draw some machines tonight, or do any other list of things.
-
-To wrap up for tomorrow, here's what I want to show:
- - load items into the dom
- - connect those items and draw their links
- - unfuck the div zoom, etc
- - ... should be ready to link-in to a node process
-
-Then I should be able to write up a decent plan, and some next steps. And clean up some.
-
-### Log 2019/03/10
-
-Things I'm going to want to squish today:
- - finishing 'view' i
- - escape key & paths ... some clean ui state elements ??
- - paths betwixt events
-
-### Log 2019/03/12
-
-.. still trying to finish view
- - receive messages for adding links, changing state (replies from manager)
- - then the link, the nested view
- - the link : manager relationship
- - the node : browser manager differences ?
-
-## The Link
-
-Ok, I think I'm up to this.
-
-Links are primarily responsible for ferring data between two contexts. This means (1) data to / from managers to / from views, and (2) normal stuff.
-
-Since managers themselves have an input and output,
- - ok, conceive of each hunk as having access to the manager.
- - .postManagerMessage()
- - this is a way for state events to bubble up, and down?
-
-Managers don't chat with Managers, they chat with Views.
-
-More like they fire events when things change (to all who are piped in to those events) and they receive messages to change things. They have one msgs input port, and one output port.
-
-Typically, these are connected to (a) view.
-
-But this is all just hookup. Links have *one* bytes -> bytes input / output (the physical data link). Then they have adaptively-added input and output ports. Typically, we hook ah link's 0th input up to the manager on the other side, and it's 0th output.
-
-So there's two different things going one: one is message passing. The other is a messaging API between the Managers, Links and Views.
-
-I think the tree -> routing thing I am thinking of is actually less productive when, i.e., I would like to connect the same context via two ports, or connect two lower level ports to one another.
-
-I think that NROL / Cuttlefish might have to be more omniscient.
-
-Things I've learned from this dom spiral are:
- - use IDs in the dom, and jQuery is nice, and store data in dom elements to disambiguate.
- - cuttlefish dom elements are unique, don't think too hard about them
- - you can build out view() pretty much independently from everything else, give it a message api pipe, a dom, and ur gravy
- - you kind of have this choice right now between a nested heirarchichal representation that acknowledges system perspective, or one that shows the network more explicily, displaying 'links' as well as 'output wires' ... or whatever that distinction is ... rather than 'hiding' the 'link' underneath a hunk of code.
-
-### Log 2019/03/13
-
-OK, do links, bootstrap node and websocket, get descriptions and then wonder about how to draw them.
-
- - button to -> string thruput -> link port -> link output log
-
-Towards the port, I want a better option for async-loading lots of things at once and then hooking them up.
-
-O shit, this is a program. OK. I write program load, fer chrissake.
-
-### Log 2019/03/14
-
-Before the weekend is out I want to do wrap *something* up. This thing is the crux: the view-link-manager holy trinity.
-
-OK, that's done, to get through the link next day there's a bit of a cascade:
- - websocket, wants state (and in program description) in order for addresses to connect
- - write that link
- - want a positioning scheme ... ? worth it ?
- - port to node, cleanup
-
-I would also, and maybe more importantly, like to clean house. This involves some writing... and chapters-not-to-miss
- - relative time scales study / chart / discussion: why we would want to be able to distribute computing *closer* and *farther away* from physical resources.
-
-And in the introduction / framing ... these are good things to spend time on / with this weekend. Put Jekyll together well enough to flesh it out.
+In my dreams, this is a way of key-parsing messages as well. I.E. I don't really want to write down a list of keys / values for manager messages - these should be locally defined by the unit that will respond to them. I am fond of that 'replyHello' implementation, and would like to extend it to all aspects of manager-ness, and think that this may be an especially helpful idea in the world of purely-serialized data and micros.
-Also, that lens, downstairs mess, furniture ... bicycle
-
-### Log 2019/03/19
-
-Last few days I drew a few clarifying diagrams, etc. What I'm going towards now is
-
- - manager available to pass messages from view that is local
- - link complete
- - node hello via link
-
-### Log 2019/03/20
-
- - looming is the flow-control in managers and views,
- - i.e (and I think both should be similar) - this is my cleanup - manager has a this.writemessage(header, content) function, that routes messages through an outbuffer
-
- so, cleanupdetail
-
- - list of messages ... ?
- up to views fun -
- - view fun (and probably very worthwhile) hunk placements ?
- - this can happen on view.loop ... ? ... rules like: links / and find their data doms, move along and stackup ?
- - hardware playtime (and wj new z axis, and design new z corner)
-
- - wrote notes down for dynamic line relaxation in code
- ... tomorrow ?
-
-### Log 2019/03/21
-
- - dynamic view is cool but will take more jujing to really sing
- - worth looking again at a different transform
- - worth rolling divtools into view (have to, divtool listeners need to talk to dom)
-
- - this is a weekend project, at least
-
- - before that, I would like to write the link, and show execution of a program across a link
- - I'll finish state updates, sending messages and receiving them in hunks
- - then cleanup of manager
- - then manager -> node
- - and then we write link ...
-
- - ... finishing the manager / view (roughly) means adding state change requests, and state change update functions to the manager
- - this requires moving divtools to the view object
-
-## On State Updates
-
-There's an awkward trick ... one way is to add to state objects a function that sends a message up through the manager on it's change.
-
-The other (maybe better) way is to, after state updates are called, send a new definition of the hunk. Assuming hunks are relatively lightweight (these objects *will* be sent over small networks) ... actually so yeah, let's keep doing that. Lightweight code in the dom, etc...
-
- - LAST CALL is adding links ! ... and the manager reply -> the view reply
-
- -> this is where you're at !
- - rming links (right click to delete)
- - also double back to manager / view check for deleting ...
-
-
- - here's a thought: since our manager replies are all description updates, we can just send as much of the description of each hunk as messages ... so to update a link, we re-write and send the output:
- hnkid_output_outputName (def)
- hnkid_state_stateName (def)
- these are heirarchichal ... draw the tree description of those messages, starting from the complete hunk
- and think about this again when you're writing messages from the cpp manager
-
- - w/r/t managing the manager - calls that require file system access can be made to a 2nd file, exported outside of manager.js - then we don't have to re-write it every time we make changes. when we make big changes next, let's do this
- - of other interest is writing a node script to read thru files and walk them between directories ... i.e. look for all browser elements without a this.dom element and copy pasta, including manager ... and the other way
-
-### Log 2019/03/22
-
- - have I finished the link / node port ?
- - if so, we are back to view, to prep for views-in-views
- - rewrite svg drawing, draw into one big local-div sized svg, go by jquery lookups
- - integrate force layout into div moving tools, do stop on mousedown, etc ... transform -> not transform
- - find a way to scale the whole div, and push its edges out ? must be a way, and it's hella worth trying
- - ... on link add, adds view also, hooks that view to that link (find a route?) - this is a cuttlefish subroutine !
-
-### Log 2019/03/24
-
-This week, I'm up to talking between two contexts. I have 'cuttlefish' (this) and 'nautilus' (node) which are near-identical implementations of a flow-controlled context in js. I am waking up websockets on both sides - the immediate task is just to send anything back and forth with two simple test programs.
-
-Then I'll be writing the link - at first just a few flow-controlled ports: these will let me experiment with putting a view inside of cuttlefish... and a nautilus bootstrap program.
-
-From there I'm going to need to stretch the manager a little bit more, the link is going to need to add / rm ports dynamically. Probably based on state, so these things will have to get worked out.
-
-Given all of this cross-domain work, It's probably going to save me lots of hassle if I sit down and carefully write a script to pull edits from the node environment into the browser environment etc. This should be true for 'link' and 'manager' especially. That means that Manager needs a file-helper on both sides.
-
-To satisfy the itch, I'll finish the ws throughput first, commit to both, and then start on the mess.
-
-The next breath I can take is when I get a view up and running of an offboard resource ... of that node server. I think I need a schedule for this, and real goals with dates attached to them, else deadline creep is going to make me sad.
-
-## View Potshots
- - escape key to leave menu (/ keys on dom ? /on new right-click etc)
- - on zoom, check if element is view or not,
- - if not view (is block) then look for event parent position, not event
-
-# Videos to Take
+# Videos to Take / Demos
- loading with view relaxation
- loading a link, spawning a view
@@ -313,4 +127,9 @@ Here's a list of things that I suspect will eventually roll themselves into bugs
- inside of the loop, it's possible for things-to-call changing during one loop iteration ? is it ?
- should not be able to add a hunk's output to its own input,
- - this also causes (probably) bugfarm when removing a hunk, as we first remove the hunk from the manager's hunks array and then we look for outputs that were connected to it elsewhere
\ No newline at end of file
+ - this also causes (probably) bugfarm when removing a hunk, as we first remove the hunk from the manager's hunks array and then we look for outputs that were connected to it elsewhere
+
+## View Potshots / UI Code Golf
+ - escape key to leave menu (/ keys on dom ? /on new right-click etc)
+ - on zoom, check if element is view or not,
+ - if not view (is block) then look for event parent position, not event
\ No newline at end of file
diff --git a/background.png b/background.png
deleted file mode 100644
index 34b40b40e1b3f3716ed638f12ebaf3bc8b10c0f3..0000000000000000000000000000000000000000
Binary files a/background.png and /dev/null differ
diff --git a/doc/IMG_2375.JPG b/doc/IMG_2375.JPG
new file mode 100644
index 0000000000000000000000000000000000000000..c6e1aefb5510c953f161aa3751f9bc1954eeac9c
Binary files /dev/null and b/doc/IMG_2375.JPG differ
diff --git a/doc/holy-trinity-2.png b/doc/holy-trinity-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..c920a2e77f08799b378a85fbbe61e3cb48454408
Binary files /dev/null and b/doc/holy-trinity-2.png differ
diff --git a/doc/holy-trinity-5.png b/doc/holy-trinity-5.png
new file mode 100644
index 0000000000000000000000000000000000000000..7d300e67e4d5a94171b4c07870886c47c82cae72
Binary files /dev/null and b/doc/holy-trinity-5.png differ