Interactive vs Batch

[Kenneth Kan]

On around page 209 (chap. 20) in the FBP book, Paul mentions how he feels that FBP is just as relevant when developing interactive applications as it is with batch systems. I'm curious if there is any large-scale precedent in this regard. I'm aware of noflo when it comes to interactive applications but that's pretty much where my awareness ends, so it'd be awesome if someone can provide some pointers.

Also, as I talk to a few people in the community regarding interactive applications, I realized that each of us has a different image of what "interactive" really means. Time and time again the discrepancy seems to goes back to simply the differing levels of component coarseness. So, with the understanding that there is no objective answer to this question, if you know of an interactive FBP system, can you also explain why the level of coarseness of such system makes sense to you?

[John Cowan]

Kenneth Kan scripsit:

> On around page 209 (chap. 20) in the FBP book, Paul mentions how he feels
> that FBP is just as relevant when developing interactive applications as it
> is with batch systems.

I understand it to mean desktop-type or web-based applications,
corresponding to the terminal-based applications of IBM mainframe days.
An interactive application is basically a loop with a break in it
representing the user as a process.

--
John Cowan http://www.ccil.org/~cowan co...@ccil.org
Most languages are dramatically underdescribed, and at least one is
dramatically overdescribed. Still other languages are simultaneously
overdescribed and underdescribed. Welsh pertains to the third category.
--Alan King

[Kenneth Kan]

That is the impression that I have as well.

The reason why I asked was because the FBP community in general feels to me that it is not too optimistic about using FBP to structure front-end development. So I'm curious as to why that is. Maybe an experiment in the past that I'm not aware of provokes that feeling?

[Paul Morrison]

I agree with John about interactive, and I have built FBP networks like that.  The kind of app I have difficulty visualizing with FBP is where you have many different windows and actions that have to be responded to, e.g. my DrawFBP app.  In this case almost all requests have to be responded to immediately and you don't really want any asynchronism.

But as you said elsewhere,

"say you have a form *field*, you type something in, it would immediately check for valid characters and highlight the field or something otherwise; it would then send an IP to the form process in the network,"

That makes a lot of sense to me!

Paul

That is the impression that I have as well.

The reason why I asked was because the FBP community in general feels to me that it is not too optimistic about using FBP to structure front-end development. So I'm curious as to why that is. Maybe an experiment in the past that I'm not aware of provokes that feeling?

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Young]

My pet project is an interactive FBP network editor, which has grown to become a fairly complete FBP program development environment.  FBP is essential to connecting component code written in a number of languages, including the underlying GraphViz editing language.   Mouse clicks in GTK code result in IPs sent to the GraphViz editor, possibly causing graphic updates.  These IPs are unbuffered, so there is no observable communications delay.   (Sometimes the redrawing operation takes a bit of time, but this is entirely within GraphViz and is not excessive.)   Multiple windows pose no particular problem.   Interestingly, GraphViz, itself, employs a simple, dynamic, piping scheme for operations such as drawing a graph.  

Tom Young
47 MITCHELL ST.
STAMFORD, CT  06902

When bad men combine, the good must associate; ...
  -Edmund Burke 'Thoughts on the cause of the present discontents' , 1770

[Kenneth Kan]

That's exciting to hear! I am curious about the fact that the IPs are unbuffered. Does that mean that these are priority IPs? Do they somehow trigger downstream processes to create a "fast path", if you will? I suppose even without the unbuffered property it should be fast enough given that there is a monolithic "component" that does all the rendering for you?

[Tom Young]

On Mon, Mar 16, 2015 at 11:23 PM, Kenneth Kan <ken...@gmail.com> wrote:

That's exciting to hear! I am curious about the fact that the IPs are unbuffered. Does that mean that these are priority IPs? Do they somehow trigger downstream processes to create a "fast path", if you will?

There is no priority scheme, triggering or 'fast path' involved.  Data flows over unbuffered Unix pipes, which block when reading until data is available and when writing until the pi

p

e is free.

>

I suppose even without the unbuffered property it should be fast enough

>

given that there is a monolithic "component" that does all the rendering for

>

you?

 I think 'interactive' implies immediate(unbuffered) processing of user input.

The editor is certainly fast enough.  The renderer, Graphviz, looks like a monolith, but actually consists of multiple, dynamically connected(not FBP), components.

"...the shell syntax required to initiate a coprocess and connect its input and output to other processes is quite contorted..."
W. Richard Stevens [Advanced Programming in the Unix Environment, p441]

[Paul Tarvydas]

Here's a backup (no sound) video of a demo I did in 2009. It shows
Visual Frameworks being used to build a GUI.

https://www.youtube.com/watch?v=8vZ8Pi32oMo

pt

[Ged Byrne]

Thanks Paul,

That looks much better suited to interactive realtime processing.

So would you say that VF is a superset of JaveFBP? Could I create a graph that behaves exactly the same as a classical FBP graph?

Regards,



Ged

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.

To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.

[Paul Tarvydas]

On 15-03-17 01:44 PM, Ged Byrne wrote:
> Thanks Paul,
>
> That looks much better suited to interactive realtime processing.
>
> So would you say that VF is a superset of JaveFBP? Could I create a
> graph that behaves exactly the same as a classical FBP graph?

I call this style bmFBP (bare metal).

If anything it's a subset or a sibling.

Unbounded queues.

One input queue per component (all pins feed the same queue and tag the
IP with pin name/number).

We add the additional constraint that a part which is composed of other
parts is considered "busy" until all of its innards have subsided.
(Parallelism starts at the leaf nodes and works its way back towards the
trunk).

Semantically, each component has its own event-loop (aka main loop).

pt