The Ceptr Puzzle

Topics: sessions, connections, runtrees, protocol specifications, error handling, processing

Sessions vs. Connections: Provide continuity across membranes for multiple receptors for interactions and building responses. A connection actually comes from an open channel to a shared common carrier as something else (like an ethernet wire, or a mic in a room)  Any mic in the room the room can hear a sound. Any MAC on an Ethernet segment can "hear" every signal on that segment.  That is a "connection" distinct from a "session" for identifying an ongoing interaction in response to a particular signal or source.

Sessions: Are clearly necessary to maintain coherence of flux/log entries, depencies as we spawn into sub-receptors for processing. The sub-receptors need to identify their responses as bound for which parent receptor's runtree they were called by and needs the result. Therefore, Session IDs are going to be generated as the RUNTREE ID of the running process awaiting response. :)

Processing: Three main types of process spawning/breeding/iterating: Sequence/sequential/series, ALL, ANY... Meaning... we're going to perform all these things in order, or we're going to do ALL these things (possibly in parallel), or if ANY of these things produce an acceptible result, we're done (also possibly in parallel, hopefully with a way to tell the other processes to abort).

Protocol revamp: Basically, we'll add "interactions" (conversations, sequences, templates) to the receptor tree structure which are a fabric for pulling together sequences of steps with expectations/actions in a templaty manner. So they generate protocol runtrees by uniting the elements defined in this receptor (or in other accessible namespaces).  Standalone protocols will emerge as a convention of sharing a set of these interactions with supporting definitions and processes as a stripped down receptor in the compository. That receptor may be INSTALLED in someone's VMhost to register the semantics of the defs/processes/interactions into their local semantic space even if that receptor is never LAUNCHED (awoken by receiving a signal directly to its flux). This seems like a pretty lightweight way to install/share protocols without creating a new kind of container that is separate from receptors.

When a signal is received on an aspect, the default response_runtree is launched (as well any other actions on triggered expectations). The session ID is set to the Runtree ID that is running and that maintains the coherence for any sub-receptor processes needed to complete the response.

Error Handling: Every Ceptr defined process will be able to have an error handling code in its def as a root level branch (code, signatures, error handling). When an error is encountered/thrown the default behavior could be to reduce the function to an error (symbol and structured values (including path to where error originated in runtree)