bergie/noflo — Issue #10: Rebase on Hook.io
Author: bergie
Created: 2011-10-11 11:31:24+00:00
State: open

Hook.io provides an actor model for Node.js
applications, and NoFlo could provide the "coordination language" for
how the different hooks are connected.

What do I mean with coordination language?
Current examples of Hook.io are a bit chaotic: any process can emit
and listen to any messages. In large-scale applications this can
easily lead to a "callback spaghetti" where events cause unwanted side
effects.
Combining Hook.io with NoFlo would provide a solution, as in this
setup hooks would listen and emit events, but the way they would be
routed to other hooks (by namespaces) would be governed by the NoFlo
network. You define a NoFlo graph, add the components (hooks) that you
need, and connect their ports (events) together. After that it would
be normal hook.io operation, except that NoFlo is also capable of
connecting and disconnecting components as needed.

The terminologies would map pretty well:

* Hook.io hook is a NoFlo component
* Hook.io hook listening to an event basically has a NoFlo inPort
* Hook.io hook emitting an event basically has a NoFlo outPort

Current NoFlo components look like this:
https://github.com/bergie/noflo/blob/master/src/components/ReadFile.c...
which is not very different from a Hook.io hook:
https://github.com/hookio/helloworld/blob/master/lib/helloworld.js

With NoFlo, Hook.io would gain:

* A way to separate hook definitions from the way they are connected
with each other
* Domain-specific language for defining these connections:
https://github.com/bergie/noflo/blob/master/examples/linecount/count.fbp
* Quite a lot of new hooks (we now have about 60 in NoFlo repository)
* Web-based UI for defining and visualizing the connections between
hooks
http://universalruntime.tumblr.com/post/8998693776/node-js-powered-we...

NoFlo would gain:

* A reliable crash-only model for the components
* Cross-network (and between server and browser) flows
* Some new very interesting components
* Better-designed event model