Joerg Heinicke skrev:
On 06.10.2006 11:35, Daniel Fagerstrom wrote:
For the JavaFlow the Abstract.Contunable.processPipelineTo uses
PipelineUtil.processToStream, it might be a good idea to copy the code
to JavaFlow to get rid of the dependency on Floscript.
The PipelineUtil in its current form depends on Rhino. Mabe the non
Rhino dependent code could be moved to the core, but I don't know if
it would be worthwhile.
IMO PipelineUtil is useful in different flow implementations and so
should be moved into core. Unfortunately - as you wrote - it depends on
the unwrap() method and so on Rhino.
Two options I see:
1. Don't access the PipelineUtil directly, but via the FlowHelper or the
AbstractContinuable in JavaFlow. The wrapper has to take care for
converting objects correctly like in unwrap().
2. The PipelineUtil gets passed a FlowHelper instance. This instance has
to provide an unwrap() method (or whatever is needed). This would
enforce an interface style instead of helper classes.
The second approach is cleaner and would enforce more parallelism in the
flow implementations.
Would also prefer the second approach.
Both approaches are probably not backwards compatible. For 2.2 this is
not that problem, but as long as we share blocks with 2.1 it is. I
wonder how long we will go this way. IMO we should decouple both before
releasing 2.2 to clean up trunk as much as possible.
Agree as well. If there is interest we should try to get out a new
(last?) 2.1.x release. And after that 2.1.x and trunk should stop
sharing code so that we can clean up trunk if we feel like it. It would,
as an example, be a good idea to start de-avalonizing some of the more
important blocks.
/Daniel
