Flow Building Blocks

[eztzachi]

• Flow Directions: By condition loops split merge support in huge array (Aviad, you are welcome to elaborate in here)
• Flow Validation (Probably the biggest advantage of Winter): Sanity check by pre/post conditions conditions will be added to any function that get the PU as a parameter pre/post annotaions to declare basic expectations from the input and what it changes in the PU run during compiling
• The flowing Object PU Style - contains a map and implement its own put/get to it

[aviadbd]

First, for terminology, I suggest using "Work Unit" for our state container, "Logic Unit" for our stateless manipulator, and "Routing Unit" for any flow element.

We wanted to be able to do a map/reduce style flow, to have flow according to predicates, and to support loops.

The bigger deal was with the validation feature, where logic units would declare what they require a work unit to contain, and what they ensure a work unit would contain at the end of the run. Further, when a method takes or returns a work unit, it must also declare the same requirements/assurances, so that the flow could be validated to make sure the work unit contains what it should across the paths of execution.

Later, these declarations could be checked via a pre-processing agent checking the code in the declared method itself.

Regarding huge arrays, it's too early to talk about that.

However, I thought it's worthwhile examining using a POJO class for the Work Unit. It's tons faster than a map, but it is more limiting - the system's logic units would need to agree on the work unit's interface in order to work. I thought of solving that using many different interfaces having the struct implementing then, therefore having the logic units support a "generics" template work unit. It should allow for a smaller memory footprint when dealing with large number of work units at once.

[eztzachi]

I agree with the names Work/Logic/Routing Unit.

I think "dynamic chain of responsibility" is a better way to describe the flow than map/reduce since we do not not break a big problem to smaller pieces, but letting different Logic unit to process out Work unit.

I can check Javalution struct for performance if you think it worth it, otherwise a simple POJO can work, but I am not sure how limit will the support be when we want to add a new java class for the WU (when we had a map<String, Object>, we could just add anything in a very simple way).

[aviadbd]

Agree about POJO. I've edited it but I guess the mail GitHub sends was without the edit. 

Let's start breaking this issue down to smaller issues - the basic building blocks and a small roadmap to merge into winter-12.

On Mon, Dec 22, 2014 at 6:46 AM, eztzachi notifications@github.com wrote:

I agree with the names Work/Logic/Routing Unit. I think "dynamic chain of responsibility" is a better way to describe the flow than map/reduce since we do not not break a big problem to smaller pieces, but letting different Logic unit to process out Work unit.

I can check Javalution struct for performance if you think it worth it, otherwise a simple POJO can work, but I am not sure how limit will the support be when we want to add a new java class for the WU (when we had a map<String, Object>, we could just add anything in a very simple way).

Reply to this email directly or view it on GitHub: https://github.com/aviadbd/winter/issues/12#issuecomment-67801891