noflo / noflo-ui

NoFlo Development Environment
https://app.flowhub.io
MIT License
767 stars 173 forks source link

Suggested enhancements to noflow-ui to support JavaFBP #370

Open jpaulm opened 10 years ago

jpaulm commented 10 years ago

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:

Additionally,

Less of a priority, but still useful are:

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 commented 10 years ago

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!

https://github.com/noflo/noflo-ui/issues/266

connection capacities

We would do this with edge metadata. Needs UI and some convention on the data itself: https://github.com/noflo/noflo-ui/issues/371, and then JavaFBP runtime needs to act on the data: https://github.com/jonnor/javafbp-runtime/issues/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 commented 10 years ago

Good point! Will do later today!

Thanks,

Paul On Sep 25, 2014 4:26 PM, "Jon Nordby" notifications@github.com 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 https://github.com/noflo/noflo-ui/issues/266

connection capacities

We would do this with edge metadata. Needs UI and some convention on the data itself: #371 https://github.com/noflo/noflo-ui/issues/371, and then JavaFBP runtime needs to act on the data: jonnor/javafbp-runtime#2 https://github.com/jonnor/javafbp-runtime/issues/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 https://github.com/noflo/noflo-ui/issues/370#issuecomment-56878552.

jonnor commented 10 years ago

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" notifications@github.com wrote:

Good point! Will do later today!

Thanks,

Paul On Sep 25, 2014 4:26 PM, "Jon Nordby" notifications@github.com 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 https://github.com/noflo/noflo-ui/issues/266

connection capacities

We would do this with edge metadata. Needs UI and some convention on the data itself: #371 https://github.com/noflo/noflo-ui/issues/371, and then JavaFBP runtime needs to act on the data: jonnor/javafbp-runtime#2 https://github.com/jonnor/javafbp-runtime/issues/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 https://github.com/noflo/noflo-ui/issues/370#issuecomment-56878552.

— Reply to this email directly or view it on GitHub https://github.com/noflo/noflo-ui/issues/370#issuecomment-56879670.

jpaulm commented 10 years ago

On Thu, Sep 25, 2014 at 4:26 PM, Jon Nordby notifications@github.com 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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

jonnor commented 9 years ago

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 commented 9 years ago

Thanks! Sounds interesting!

All the best,

Paul

On Wed, Jul 1, 2015 at 6:40 PM, Jon Nordby notifications@github.com 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 https://github.com/noflo/noflo-ui/issues/370#issuecomment-117843180.