C# support

[peterclemenko]

Support for C# would be useful for those of us in Unity land.

[jonnor]

Certainly. It basically amounts to sending/receiving messages over a supported transport like MQTT or AMQP, and then then sending to fbp topic the JSON discovery message.

Initially it is also possible to skip the discovery part, and use msgflo-foreign to send it.

I'm not familiar with C#. But I'm happy to help if you get stuck with anything.

[peterclemenko]

Alright, thanks. I'm getting back on the swing of things after a diversion. Not sure if you would have this information, but how/what protocol is noflo ui using to communicate with msgflo? The first step on my end is trying to implement a UI for FBP on Unity3D (Alas, 2D interfaces like flowhub don't work well for what I'm trying to use it for, I'm trying to do a full VR/AR implementation) and I'm trying to figure out how/what msgflo receives from noflo ui (let alone what noflo ui is actually doing in the composition of flows and how it is communicating it, but that's for the noflo ui tracker).

The second part would be what would be needed to add noflo for C# runners. There are some C# FBP things out there already, but nothing supports the fbp protocol or file format yet. Trying to figure out if that would actually be needed.

[peterclemenko]

Reading up more, additional documentation on how to add foreign participants, specifically on how they are handled at a code/communication level would help as well (IE do I need to do anything special to get it going, tutorials on going from a simple command line hello world to a foreign participant) would be helpful as well.

A tutorial on how to create a basic new runtime and what is needed for full functionality would help a lot. The documentation seems to me like it's lacking in that element, especially with regards to tutorials.

[jonnor]

Your questions span a lot of different things. To cover the MsgFlo aspects:

A MsgFlo foreign participant is any code that can talk MQTT/AQMP on some queues/topics. Then the FBP-style metadata is declared in its own file, and msgfo-foreign sends this metadata as a discovery message on behalf of the code. Example declaration for a microcontroller-based IoT button/switch: https://github.com/c-base/c-flo/blob/master/components/BigSwitch.yml

A MsgFlo (whether foreign or 'native') does not need to be a FBP runtime internally. In fact most participants are implemented as imperative/functional/object-oriented code following the common conventions of the language/platform. See example code in msgflo-nodejs, msgflo-python, msgflo-arduino etc

So with MsgFlo the FBP component/graph programming model is only* of how these participants talk to eachother, by configuring the corresponding message queues in the message broker (RabbitMQ,Mosquitto). Nominally each participant is a separate process (on operating system level), often spanning multiple devices/servers.

* integration between the FBP concepts on MsgFlo level and inside an FBP based participant (NoFlo,MicroFlo,) is planned in the future

[jonnor]

Flowhub (noflo-ui) communicates with MsgFlo (and any other runtime) using FBP runtime protocol, typically over WebSocket. https://github.com/noflo/noflo-ui#usage-with-different-fbp-systems

So if you want to implement your own UI, that is the protocol you need to implement. In addition to the protocol reference linked above, you can look at the communication between Flowhub and an existing runtime to get a better understanding of it.

[peterclemenko]

Alright, thanks, much appreciated. I did notice another thing I was wondering which is how to set up a namespaced multi system msgflow environment (ie /internal/nmap/scan) and (/external/nessus/scan) however I think that should go in another issue. The documentation seems to be the biggest stumbling block for me. I know read the code is the holy grail, but a few tutorials guiding this stuff a little more and a little more verbosely on the docs page would really help with adoption and integration.