there's something in the currently 'approved' usage of Pipes and the various demos out there that has been bugging me and I thought I'd open it up for discussion here.
I'll try and get my point across as clearly as possible.
The crux of the matter is that all code I've seen is assuming that modules have a single output Pipe named PipeConstants.STDOUT and that, to some extent, this assumption seems also to be built in to JunctionMediator (on a subconscious level, if you like). This contrasts with the generic way that the IPipeAware interface requires a pipe name as its first argument and the fact that JunctionMediator and Junction can handle any number of output pipes.
What I am wondering is whether the use of STDOUT has developed as an easy workaround to this slight discrepancy in the framework?
So, currently, this is the workflow:
- Module-to-shell pipe is created
- Module-to-shell pipe is passed to module using STDOUT name
- Module-to-shell pipe is registered by JunctionMediator
- To send a message to shell, the module uses the STDOUT name to specify the output pipe
That last step is what's bugging me, as it seems to be unnecessarily inferring knowledge of the shell architecture. It also limits the flexibility of JunctionMediator because although any number of output pipes are supported, the sendMessage() code always reverts to just a single pipe.
Since the module doesn't really know in advance what pipes it will be connected to, I reckon it would make more sense to send messages to all available output pipes.
The problem is compounded in some way by the fact that Junction provides no method for retrieving all output pipes and JunctionMediator doesn't store the output pipe names when they are registered, so this information isn't accessible.
To improve flexibility, it would be enough to add a single method to Junction, which would send messages to all available output pipes.
Does anyone else have any thoughts on this matter?
Cheers - Nils.