XML::SAX::Machines is probably half of the framework one needs to get something like this going. I've looked at FBP (or what I've previously considered in perl as Perl Beads), and while the concept is easy to conceptualize and start to put together, the more difficult part is working on the standard that you would use for the data transfer. Using XML as intermediates makes great sense here, so this might be the best way to go.

Right now, without having done anything yet with X:S:Machines, the problem that I envision is the issue of synch vs asynch operation. My understanding is that with Machines, say you chain 100 filters on it with one generator object. When I send any SAX event from the generator object, that event has to be handled by each filter in order, assuming that those filters process and resend the event upstream. But now that I type this out (don't you just hate that? :-), I realize that one can have filters that get sax events but don't do anything until certain conditions are met. This would be necessarily in a case where one might have a Machine that worked line-by-line on a file, but diverged at some point to two different processing paths, and then remerged back to a single path. At some point, at the merge, you need to make sure that you don't send the data upstream until you get a matching set of elements from the divergant point. Again, here's where XML comes in handy, because these bits of XML that 'flow' around would contain history of where they came from and where they're going.

I was thinking about FBP earlier this week and saw the Machines article on perl.com, so I'm considering trying it this weekend to see if something reasonable can be done.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important