Tuesday, May 5, 2015

Writing an FBP program means, essentially, describing a graph or network of components, their interconnections, and certain initial conditions. Currently, there are three ways to describe an FBP program:
  1. Programmatically. For example, the following is an excerpt from Java program that uses the JavaFBP library of Paul Morrison:
    protected void define() {    
        connect(component("Read", ReadFile.class), port("OUT"), 
                component("Write", WriteFile.class), port("IN"));
        initialize("testdata/testdata.txt".replace("/", File.separator), 
                  component("Read"), port("SOURCE"));
        initialize("testdata/output".replace("/", File.separator), 
                  component("Write"), port("DESTINATION"));
      }
    Similar examples exist for other languages.
  2. Using the FBP Network Protocol. This transport-independent protocol is promoted by the NoFlo group. You can see it in action by watching the Websocket traffic between the NoFlo Development Environment and protoflo, a Python implementation of FBP.
  3. Using a DSL. There is a language, supported by NoFlo and Morrison, that can be used to create a textual description of an FBP graph. More about the language can be found here and  here. This is an example ('#' indicates a comment line):
    # Read the content of "somefile.txt" and split it by line
    'somefile.txt' -> SOURCE Read(ReadFile) OUT -> IN Split(SplitStr)
    # Count the lines and display the result
    Split() OUT -> IN Count(Counter) COUNT -> IN Display(Output)
    # The read errors are also displayed
    Read() ERROR -> IN Display()
    
No matter how it is described, the execution of an FBP program begins by instantiating components as processes. The presence of Initial Information Packets (IIP's), typically parameters or initial conditions and/or Information Packets (IP's) at a component's input ports will trigger its execution. The result of an execution is, typically, the sending of IP's to other, connected, component processes.

This process architecture suggests a way to begin the Elixir implementation: by developing the functions to create and execute a graph or network representation. Erlang has a library for just such a representation: digraph. While Elixir is syntactically different from Erlang, the Elixir programmer still has direct access to all of Erlang's many libraries. Jordan Damov, in one of his posts about Elixir, shows how one can use the digraph library. 

Graphs, then, will become the base for our design. The FBP ideas translate well: the nodes in the graphs will be Elixir processes and communication between the nodes will be performed asynchronously by sending messages to these processes. 

A final note: Morrison describes the differences between the original or "classic" FBP and the NoFlo implementation of FBP. I plan on implementing the classic version.

No comments:

Post a Comment