routes

[nikhan]

No more query routes and rules.

Instead, every block has a number of inputs, a number of outputs, and a number of states.

Inputs
The only parameter an input has is path. This allows a user to specify where in the incoming JSON object to look. This path parameter is a simplified version of gojee, such that, it always returns a single value or it returns an error if a value is not found. It removes the capability of doing a query across array elements, such that .foo[].bar is no longer a valid (.foo[0].bar is still valid, however).

Instead of rules, there are a number of inputs. For instance: a count block would have a msg input and a window input. The window does not accept rules, it accepts a stream of parameters that are used to effect the state of the block. These parameters would look like a stream of strings, 30s.

(depends on #3)

State
Each block can have a number of states. These states can optionally have a pollable input pin/output pin emitter as well as an HTTP endpoint. The benefit of having a state over our current implementation is that it combines the functionality the production of a message for an HTTP endpoint as well as for the rest of the ST system, meaning a block author does not need to write multiple bits of code that do the same thing.

Outputs
Instead of having a single output, a block can have multiple outputs. These should be able to be named.

[mikedewar]

does state == rule?

[nikhan]

❓

[nikhan]

States are any information the block needs to paramaterize its function.

*edit I realize that this is wrong usage of the word "state" but the point still stands

[mikedewar]

in streamtools there's quite a distinction between rules (like Interval) and states (like Count). I think you're getting rid of that.

[nikhan]

there is a distinction because you can't send a message and set state Count
you can send a message and change Window

[mikedewar]

ok so in st-core there are no rules

[jacqui]

I like this new system of anarchy.