Suggested enhancements to noflow-ui to support JavaFBP

[jpaulm]

Given that @jonnor has successfully driven a JavaFBP network from a JSON network definition - which, in turn, can be generated from flowhub, it seems to me that flowhub will need a few more features to allow it to generate whatever JavaFBP needs - and of course bridging constructs will have to be added to the JSON. The two main requirements that leap to mind are:

• top-down design, with subnet explosion or suppression - remember that, for this case, you don't even know how many ports the block expects!
• connection capacities - you can see how we do it in DrawFBP at the bottom of https://github.com/jpaulm/javafbp-websockets/blob/master/README.md , but I believe your technique is to add attributes to the ports. Since in JavaFBP, connections correspond 1:1 to input ports, this would seem the easiest place to define capacities under flowhub

Additionally,

• since in JavaFBP we allow many output ports to feed one input port, but not the reverse, it would seem appropriate to have flowhub check for the reverse case, and either disallow it, or automatically generate a copy process

Less of a priority, but still useful are:

• "automatic ports"
• "drop oldest" (discussed in an earlier topic - https://groups.google.com/forum/#!searchin/flow-based-programming/oldest/flow-based-programming/WftVUf0Q5w8/OYUKOFyI7Y8J )

You may want to set a "classical" mode switch on the start of the diagramming process, to enable some of these features. I know modality is often frowned on, but I think such a switch is justified, as the two styles of thinking are so different! If users are going to use flowhub for production "classical" FBP work, it wouldn't hurt to give them whatever on-line guidance you can!

There is a fairly complete list of DrawFBP features given in https://github.com/jpaulm/drawfbp/blob/master/README.md - of course, you can pick and choose from these, depending on what fits the flowhub philosophy, and/or the needs of your users.

@forresto I know I sent these in a note, but I thought this would allow these enhancements to be tracked more easily.

[jonnor]

Hi @jpaulm,
if we are ever to track progress on these feature requested we need to split them up. We can keep this issue for discussion on things that are unclear.

top-down design, with subnet explosion or suppression - remember that, for this case, you don't even know how many ports the block expects!

#266

connection capacities

We would do this with edge metadata. Needs UI and some convention on the data itself: #371, and then JavaFBP runtime needs to act on the data: jonnor/javafbp-runtime#2

"automatic ports"

What is this?

You may want to set a "classical" mode switch on the start of the diagramming process, to enable some of these features.

The user should not be require to flip a switch themselves. We ask the runtime which capabilities (not mode, more finegrained) it has, and then we expose features based on that.

[jpaulm]

Good point! Will do later today!

Thanks,

Paul
On Sep 25, 2014 4:26 PM, "Jon Nordby" [email protected] wrote:

Hi @jpaulm https://github.com/jpaulm,
if we are ever to track progress on these feature requested we need to
split them up. We can keep this issue for discussion on things that are
unclear.

top-down design, with subnet explosion or suppression - remember that, for
this case, you don't even know how many ports the block expects!

#266 #266

connection capacities

We would do this with edge metadata. Needs UI and some convention on the
data itself: #371 #371, and
then JavaFBP runtime needs to act on the data: jonnor/javafbp-runtime#2
jonnor/javafbp-runtime#2

"automatic ports"

What is this?

You may want to set a "classical" mode switch on the start of the
diagramming process, to enable some of these features.

The user should not be require to flip a switch themselves. We ask the
runtime which capabilities (not mode, more finegrained) it has, and
then we expose features based on that.

—
Reply to this email directly or view it on GitHub
#370 (comment).

[jonnor]

I already created tickets for the ones that I am clear on, see the links.
Feel free to add others ones though
On Sep 25, 2014 1:34 PM, "jpaulm" [email protected] wrote:

Good point! Will do later today!

Thanks,

Paul
On Sep 25, 2014 4:26 PM, "Jon Nordby" [email protected] wrote:

Hi @jpaulm https://github.com/jpaulm,
if we are ever to track progress on these feature requested we need to
split them up. We can keep this issue for discussion on things that are
unclear.

top-down design, with subnet explosion or suppression - remember that,
for
this case, you don't even know how many ports the block expects!

#266 #266

connection capacities

We would do this with edge metadata. Needs UI and some convention on the
data itself: #371 #371, and
then JavaFBP runtime needs to act on the data: jonnor/javafbp-runtime#2
jonnor/javafbp-runtime#2

"automatic ports"

What is this?

You may want to set a "classical" mode switch on the start of the
diagramming process, to enable some of these features.

The user should not be require to flip a switch themselves. We ask the
runtime which capabilities (not mode, more finegrained) it has, and
then we expose features based on that.

—
Reply to this email directly or view it on GitHub
#370 (comment).

—
Reply to this email directly or view it on GitHub
#370 (comment).

[jpaulm]

On Thu, Sep 25, 2014 at 4:26 PM, Jon Nordby [email protected]
wrote:

"automatic ports"

What is this?

Described in Chap. 13, p. 132 and following. It is represented in DrawFBP
by a blue dot at the appropriate end of the arrow.

You may want to set a "classical" mode switch on the start of the

diagramming process, to enable some of these features.

The user should not be require to flip a switch themselves. We ask the
runtime which capabilities (not mode, more finegrained) it has, and
then we expose features based on that.

I am not so sure - the "classical" FBP and "reactive" FBP ways of thinking
are so different that I think it would be useful to make the user specify
right at the beginning which mode s/he is going to be working and thinking
in.

As a simple example: one output port feeding multiple input ports is legal
in NoFlo, but illegal in JavaFBP, C#FBP and C++FBP - and in fact the
infrastructure does not support it.

Your comment about "capabilities" suggests a mix-and-match approach, which
IMO won't work.

HTH

Paul

[jpaulm]

@jonnor @forresto Any action on these requirements, posted about 9 months ago? @kenhkan tells me there is a new alpha version of FlowHub out - not sure where issues should be posted...? TIA

[jonnor]

No progress. I did not end up using JavaFBP/Flowhub in the application I prototyped it for, so it has been low priority for me to improve it. Had to do other things like MsgFlo.

Issues with Flowhub should be posted in this Github project.

[jpaulm]

Hi @jonnor, thanks for your quick response! Could MsgFlo talk to JavaFBP if we built an AMQP interface JavaFBP component? Regards

[jonnor]

Hi @jpaulm. Yes, JavaFBP+MsgFlo is plenty doable. It could be a set of JavaFBP components or a "loader" that sets up the JavaFBP network and exposes certain in and out ports.

[jpaulm]

Thanks! Sounds interesting!

All the best,

Paul

On Wed, Jul 1, 2015 at 6:40 PM, Jon Nordby [email protected] wrote:

Hi @jpaulm https://github.com/jpaulm. Yes, JavaFBP+MsgFlo is plenty
doable. It could be a set of JavaFBP components or a "loader" that sets up
the JavaFBP network and exposes certain in and out ports.

—
Reply to this email directly or view it on GitHub
#370 (comment).