#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 - idea is to use 'visualization strategy' in the light point objects in the stitie space, assigned by a 'coordinator objets' that command whole groups of objects around these,
- There should be model-forming server grid, visualization-serving recursive
tree-hierarchy of clusters, visualization-ordering clients that can order visualization of any precision level; clients can contact model-interaction cluster server with commands; with marching cubes algorithm, stitie space recursion & visualization cluster, model can be visualized in any precision, with camera positioned at any location, orientation & zoom; groups of objects in model can be simplified in visualization using triangles & rectangles .... then this visualization can be treated as amodel as well, and group of adjacient 'cubes' can be simplified again as a single cube - this process can be repeated as much as we need, recursively, Recursive spaces of 3x3x3 resolution seem natural, but design does not disallow other resolutions, does not enforce recursion as well.
- 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,
- Considering Forms/Transition Graph in the MATEN Forms Invocation functionality; visual support (using Mindful Imaging, perhaps interactive dynamic interaction as well) for form/transition graph - including 'form invocation history', 'current form detection method & form detection history'; there should be 'no-form' & 'empty form' as two of possible detected forms, Let's note that forms can have inheritance tree, can be more or less abstract/concrete as well. 'What-is' relation should consider coordinates of form's parts, not only types, states & strategies in Space.
- Considering PRISM functionality to use both coordinates list, as well as Stitie Machine names list.
- Considering automatic linking & unlinking of adjacient machines, considering recursion & machine movement in space as well.


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 globally-unique & location-independent names. Threads will have globally-unique & location-independent names as well.
3. Planning to include 'name-location' 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,
- location within a space-recursion hierarchy.
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