I'd suggest to implement FBP protocol as a separate library which in turn could be used as a dependency for this one. In my opinion the protocol would be too much implementation detail for this lib.
Also it would be more open for integration into other tools.

@maschmann in noflo we do have fbp and fbp-protocol dependencies. https://github.com/noflo/noflo/blob/master/package.json#L18

@aretecode first of all: Thank you for reviewing, the good feedback and merging 👍

BTT: I am not sure how to integrate the endpoint for FBP protocol :-)

Some other questions also bother me for some time now: Is async for those processes (php context) the correct approach since most php programming is done in the synchronous way. Background for this concern is my current work with data import and transformation. If you have a workflow where you build a dataset from different sources through several processes and use dependencies for those processes (what the bundle allows), you have the Framework or whatever else you use with phpflo always boot up for every process, including DIC build, etc. which considerably decreases performance and also logistics due to missing shared state of the framework. Communication between threads/processes is also really difficult to master in that scenario. In a standalone scenario (only phpflo & some components) it should be easy enough: But how often is this the case?
Maybe this is easy to solve - but as of now I don't see a useful solution.

btw: Flowtrace would be a really nice-to-have feature. Have spent a few hours figuring out how the logging format should look like and where to catch the communication between the processes.

@maschmann

Good points and questions! :-)

Async

Asynchronous is not necessary in PHP. It makes things more complex to manage.

State

There are plenty of ways to share the state, in some noflo repos we use something similar to a Registry. You could pass in whatever part of the framework in a port and update it.

Performance

Loading everything without long running processes, the startup time is not optimal, and in PHP it is difficult to improve drastically. Benefits vs negatives right.

Flowtrace

Wouldn't you be able to listen to the event emitting from the sockets?

P.S...

Process API

https://github.com/noflo/noflo/blob/master/src/lib/Component.coffee#L93
Is really nice to use in noflo.

FBP

The other option is using https://github.com/flowbased/fbp to convert FBP to JSON so people can still write FBP.

Did that answer most of it or did I miss anything?

@aretecode thanks for the time and the explanation :-)

To summarize the next steps:

• Async not at first, because of unnecessary complexity
• Since async is not an issue, state is solved (for now)
• ... as is performance
• trace: will have an endpoint in the InternalSocket
• I'll check on the current component implementation for the process API

If I have more questions, I'll bother you again :-)