Henri Bergius

@jpaulm the difference is that while DrawFBP is editing abstract graphs, NoFlo UI/Flowhub is usually used in connection with a live runtime, meaning that any graph changes cause changes to...

@jpaulm well, yes. Hence this ticket ;-) What we support is bottom-up design (start by building components, then connect them), but I totally agree with @trustmaster that supporting top-down design...

Just realised that the [MsgFlo foreign participant registration format](https://msgflo.org/docs/foreign/index.html) is roughly what we'd need for specifying non-implemented components

Current UI sketch for defining component interfaces: 

@akonsu noflo-ui isn't unfortunately yet aware of arrayports in a proper way. See #14 and the-grid/the-graph#51

The workaround for this with current noflo-ui is to use a set of other components (for example, `core/Repeat`) and edit IIP in those, and forward to correct index of the...

@alfa256 this would also need runtime protocol-level support, unless we send `removenode` and `addnode` commands to runtime on disable/enable.

The other option is using Bluetooth. Should be reasonably easy to set up if running the MsgFlo coordinator on Raspberry Pi (like we will with https://github.com/c-base/c-flo): https://medium.com/@urish/exploring-the-physical-web-without-buying-beacons-efae51e36c2e#.d4xwmmkxr

It seems one option would be [UPnP/SSDP version of Physical Web](https://github.com/google/physical-web/blob/master/documentation/ssdp_support.md), which is [reasonably straightforward](https://github.com/fraunhoferfokus/phyweb) to support with Node.js without additional hardware. However, see the discussion in google/physical-web#619 Right now...

Example: [msgflo-hono](https://github.com/msgflo/msgflo-hono)