[Home]Fluix

FlowBasedProgramming | RecentChanges | Preferences

FLUIX is a Flow-Based Programming (FBP) toolkit targeted for XML. It's ideally suited to process big XML documents but is also packed with functionality not specially related to XML. You can download a copy at http://sourceforge.net/projects/fluix/

See FluixExamples to get a taste of FLUIX programs.

Related work

All the concepts in FLUIX are not new. The java implementation uses the same terminology and ideas found in PaulMorrison's book. Although FLUIX may resemble the JFBP (now called JavaFBP) toolkit by PaulMorrison it has some nice ready-build blocks that can help you solve stylesheet related problems.

FLUIX also adds some (new) ideas that are not found in JavaFBP:


Compiling

Compiling Networks or other Processors is also done by Processors. For instance, the input of a NetworkCompiler? is the Network definition. The output will be a compiled Network that can be the input of another Network.

This sounds interesting! I look forward to finding out more.

Related are LispMacros. Another interesting idea is SuperCompiling?. See http://www.supercompilers.com/ for more info.


Loops

Loops are not allowed in Networks so deadlocks can be avoided as much as possible. If you want to 'loop' something you can use a specialized Foreach component instead.

I am having a little trouble with this point:

- I agree that loops in the network are more conducive to deadlocks, but "loops" also includes divergent/convergent topologies, and I am not sure how you would ban these, unless you have some pretty smart graph theory. Would you not be giving up some of the power of FBP?

- Foreach sounds like "for each incoming data object" - i.e. logic within a process. How does it have any bearing on loop network topologies which have to do with flows between processes?

Please excuse my confusion!

You are right that divergent/convergent topologies can also cause deadlocks, but this is almost always a design problem related to ordering. And, you are also right that you cannot ban these without losing the power of FBP.

I have not needed loops because I use the Foreach processor for looping (and because looping Networks tend to confuse me!).

Still, I believe only a DirectedAcyclicGraph should be allowed. Topologies with cycles are more probable to deadlock during runtime. I've come to the conclusion that you can build any functionality without the need of looped topologies. I've no hard evidence to back this last statement but some proof of it can be found at http://www.haskell.org/tutorial/functions.html.

The Foreach processor I suggest can be seen as a HigherOrderFunction - a function that takes another function as an argument, for instance the map function.


Immutability

All Values passed between Processors are immutable. This promotes the use of a Functional Programming style because mapping input to output (with no side-effects) is one the fundamental building blocks of FBP. The AdvantagesOfFp are just too many.

This sounds good also! Since what is passed between processes in FBP is streams of data objects (InformationPackets), I assume this means that any data objects received by a process will be garbage-collected, and a new one allocated, even if the content is the same. I agree this is cleaner, but have you thought about the overhead - especially since in FBP you can have TreeIPs flowing between processes. Alternatively, maybe we can take advantage of the immutability to improve storage allocation. --PaulMorrison

And because they are immutable we open the possibility to share Values across processes! (via shared memory). If they weren't we'd never be sure about the real value of an IP. For instance, the IP could have been altered (secretly) by a malicious program.

The overhead of TreeIPs flowing between processes is certainly problematic. Still, this can be solved by sharing as much data possible between (consecutive) TreeIPs. It is proven that, if a tree is well balanced, a non-destructive 'update' can be done in O(log(n)). With more advanced algorithms this can even be reduced to O(1).

The downside is that sharing data-structures across many processes may introduce too much RandomAccess?. This defies optimizations that require locality of data such as caching.

Note that sharing data (ImmutableStore) is also related to our other discussion on FlowBasedTransactions.


Why use it?

Because with FLUIX you can build programs more intuitively and fluidly than ever before.


Update! (20040211) The last two weeks we were very busy pushing FlowBasedProgramming concepts to production - that's why I didn't participate in the discussion - sorry about that! Still, we got some real FBP stuff working and we can say that it rocks! -- RobbertVanDalen

Fantastic! Send us some sample code to give a flavour of what you have done! --PaulMorrison

Sorry, I cannot give any source code, because it is owned by my employer! It is also not coded in FLUIX but in another (related) version of FLUIX. I will try to translate some of the code to FLUIX to give an idea of what we have done --RobbertVanDalen

Just a general idea would be great! What application area? How does it differ from FBP? Will there be papers coming out about your work? --PaulMorrison

-- Update (20040225). I just finished moving my house so I wasn't able to anwser promptly. Anyway, the application area is financial and banking applications. See FluixApplications.


FlowBasedProgramming | RecentChanges | Preferences
This page is read-only - contact owner for a password | View other revisions
Last edited November 14, 2004 10:43 am by PaulMorrison (diff)
Search: