4

NoFlo Components documentation mentions groups but doesn't explain what they are used for and how they should be used.

Could somebody explain what role groups play in NoFlo, how groups and nested groups should be used and how it affects Asynchronous components?

1 Answers1

3

The concept of groups is described as "bracket IPs" in the FBP book.

Basically begingroup and endgroup are special packet types that specify that data packets sent between them contain that group as metadata.

Think of it a bit like XML:

<somegroup>
  <innergroup>
    data
  </innergroup>
</somegroup>

In NoFlo this would work with:

@outPorts.out.beginGroup 'somegroup'
@outPorts.out.beginGroup 'innergroup'
@outPorts.out.send "data"
@outPorts.out.endGroup()
@outPorts.out.endGroup()

The receiving inport gets these via the begingroup and endgroup events and can either do something with them or ignore them. Usually a good behavior with components that don't utilize groups but perform some transformations on information packets is to at least pass them onwards.

@inPorts.in.on 'begingroup', (group) =>
  @outPorts.out.beginGroup group
@inPorts.in.on 'data', (data) =>
  # do something and then send
@inPorts.in.on 'endgroup', =>
  @outPorts.out.endGroup()

So, groups can be seen as a way to supply some "metadata" for your packets. For example, NoFlo's when filesystem/ReadFile sends the contents of a file out as a packet, it surrounds it with a group named with the file's path.

Groups can also be super-useful for merging asynchronous flows. For example, webserver/Server generates a unique group identifier for every request it gets. If you do database queries or other async operations before responding to a request, you can use these groups for merging the results back before writing a response.

bergie
  • 930
  • 7
  • 8
  • Could you explain how groups should be forwarded in the following scenarios? (a) multiple in ports and a single out port (b) a single in port and multiple out ports (c) an optional in port and a required in port (d) any other combinations to note – Paul Young Aug 03 '14 at 02:32
  • 1
    @PaulYoung That's component-specific or even app-specific. Generally groups should be forwarded as they make sense (e.g. request ID, URL) to the route where they are likely to be utilized, so: (a) from one or several main inports to the outport, (b) from the in port to those outs which are sensitive to group data, (c) from the required in port only most likely, (d) WirePattern's forwardGroups just forwards everything it gets on its inputs to all the outputs, so don't use it if you need custom forwarding schema. – trustmaster Aug 05 '14 at 19:47