PipelineUtil (was: svn commit: r453409)

[Joerg Heinicke <jo...@gmx.de>]

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.

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.

> The main point with the move of PipelineUtil and the unwrap method, was 
> that I wanted to get rid of the dependency on Rhino in core.

Yes, I know.

Jörg

Re: PipelineUtil

[Giacomo Pati <gi...@apache.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 8 Oct 2006, Daniel Fagerstrom wrote:
> Joerg Heinicke skrev:
>>  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.

I'd support your release plan as well the de-avalonizing of 
important blocks.

- -- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFKWTTLNdJvZjjVZARAqgoAKCvJod/m9zTHWxajTTSV4GYxdmdQACgkYVI
1PtJoxEUI0ECo69ZOQDZoDM=
=z6NF
-----END PGP SIGNATURE-----

Re: PipelineUtil

[Daniel Fagerstrom <da...@nada.kth.se>]

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