Stitie Machine 1.2.1 Alpha 0-0-18 'Satellite' implementation is available.
(RC stands for: 'Release Candidate', Alpha means 'feature incomplete', Beta means 'feature complete, to be tested').
ideas to be included:
- Stitie Machine's Communication Shortcuts,
- Code's Elements' Visualization & Kabbalah,
- Stite Machine movement, Peer-2-Peer Network Communications & Stitie Space services for Client Objects,
- Atomic & concurrently isolated 'put multiple values into state' & 'lock state for thread(s)' functionalities; it's useful in many possible cases, for example when 'running Strategy as a thread' for keeping critical sections atomic & concurrently accessible - so process' 'instruction pointer' can move in 3D over object's graph in a visuospatial way without deadlock in case of moving in a graph's cycle or with a Recursion.
Stitie Machine movement is included in the code already (in a SitieSpaceImpl class, as it should be) - just need to properly care for concurrency, and update router's coordinates if it's not done (automatically or not) already - need to check.
Update of 29.06.2017:
Planned redesign & reimplementation of Stitie Space 1.2 package for robustness (fault-tolerance), scalability, speed, agility (more of well-thought convenience methods) & code quality.
This has uses in 'Ola AH' Programming Language project.
This is more of a focus on the distributed programming, but whole space with objects & services is still runnable on a single computer system. Minimal hardware costs, memory costs & cpu-time costs will increase slightly, but scalability costs, ease of use, code efficiency, code quality & robustness should improve very much.
Planning to use JUnit tests as well.
1. Container Objects holding multiple objects at a single machine. Concurrent & Delegating.
2. Both StitieMachines & Objects will have qualified names (Space hierarchy in case of recursion of spaces within spaces will be included, as well as an optional parent container object & 'this' object). Threads as well (with full qualified name of Machine within Space hierarchy, optional parent container object, 'this' object name & thread name).
3. Planning to include 'name-loction' service available via space or independently to aware objects. Should be replicateable for robustness, scalability & speed.
4. 'name-location' service should manage & make avialable data about:
- machines names,
- object instances names,
- coordinates of machines, object instances or 'moving to coordinates' information with destination coordiantes included,
5. Thread location & access service considered, exact details not soldified yet - perhaps will change. So far idea is that threads will be attached to objects & executed within machines. Threads should be located by machine name, optional parent container object name, contained object name that holds a thread & a thread name. Thread migration between objects should be handled manually by a programmer. When object moves to another machine however, it will carry it's threads with itself to another machine. Thread communication will be handled manually, but can use this service.
6. Space should contain data about reserved coordinates for moving machines, both corridors for movement as well as 'teleport' movement reservations. Should be well thought about concurrency issues. Events about machine or object arriving at destination should be considered as well - probably these will be delegated to 'event executor' service.
7. We should design & implement the 'routing service', replicated for robustness, speed & scalability, available via space or independently.
8. Separate replicated 'Space State' and make it available to Space-Handling Services with proper permission, as for example: Space Access services, Mindful Imaging Service, Security Service (giving encrypted & signed permissions, leased for a given time or until completion of the task - whichever comes earlier), Routing Service, Route-Reservation Service (should use routing service as 'subcontractor'), Name-Location Service, Event Execution Service, Thread Location & Access Service, ... ; Exact amount, names & responsibilities of services around replicated 'Space-State' is to be considered yet. The values in space-state array should be of abstract type: ObjectAtCoordinates; Concrete classes of this type should be: StitieMachine, EmptySpace (Without Router, Space & Strategy), ReservedSpace (Without Router, Space & Strategy), PhysicalObstacle (Without Router, Space & Strategy).
9. Consider making Stitie Space Service a Facade Design Pattern for Space handling services ease of use, that will delegate to separated & independently secured services around 'Space-State'. Objects should be able to be clients of either these low-level services for security & speed, or clients of this facade for ease of use. Direct access to space-state should be denied to them, available only via services around 'Space-State' or via this facade.