#header-inner {background-position: right !important; width: 100% !important;}


Stitie Machine 1.2 'Satellite'.

Stitie Machine 1.2.1 Alpha 0-0-19 'Satellite' implementation is available.

(RC stands for: 'Release Candidate', Alpha means 'feature incomplete', Beta means 'feature complete, to be tested').

ideas to be included:
- Java 8 for functional programming methods; we want lowest possible Java version that include functional programming methods,
- JUnit Tests, perhaps with Mock Objects - this should speed up rewriting of Stitie Machine & Space & make it more robust,
- Complex Strategy as a separate class, with access to two lists in State - Selected, Sorted Strategies (Complex or not) & All Strategies (Complex or not).
- 'Tree Strategy' using Complex Strategy, as lists of lists with functional programming,
- Comparator that selects logically strategies to execute in a Complex Strategy,
- Comparator that sorts strategies to execute in a Complex Strategy,
- Retrieval of selected strategies from Complex Strategy's State,
- Events Support,
- Event(s) included in a Strategy,
- Comparators realized as a State & Strategy, with an option to use Complex Strategy,
- Stitie Machine's Communication Shortcuts,
- Code's Elements' Visualization & Kabbalah,
- Stite Machine movement, Peer-2-Peer Network Communications & Stitie Space services for Client Objects,
- Support for voxel graphics & marching cubes algorithm in Mindful Imaging,
- 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.

Design changes:
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.

No comments:

Post a Comment