Pipes, STDOUT - limits in current practice

[nilsm]

Hi everybody,

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.

[puremvc]

The STDIN and STDOUT pipe names are not defined in the utility itself. You don't have to use them at all. They were defined in a demo and others have followed that example.

To improve flexibility, it would be enough to add a single method to Junction, which would send messages to all available output pipes.

You don't always want to send all messages to all output pipes. For instance in the Sea of Arrows site http://seaofarrows.com/srcview there is a Shell, a PlaylistModule, and a VisualsModule. The Playlist sometimes wants to talk to the VisualsModule only, which it does on a pipe named the same as the VisualsModule.NAME. Sometimes it wants to talk to the shell which it happens to do on STDOUT, though it could've easily been STDSHELL. The point is your module makes the decision about which pipe to send a message out. What goes into that decision is all up to you and your plumbing.

   * 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.

In a Module you may have any number of input and output pipes, and they may be named whatever you want them to be named. That's why the STDIN/OUT constants aren't defined in the Pipes utility itself.

-=Cliff>

[nilsm]

Hi Cliff,

thanks for the quick response.

I didn't really see the need for centrally-defined pipe names at all, since that seemed to limit the flexibility.

Your example's helped - after all, if you did connect several output pipes to the same module, the module still wouldn't know which pipe to use to send messages on, if it weren't for the centrally-defined pipe names. So this piece of shared knowledge is necessary after all.

Thanks for the clarification,

- Nils.

[mariusht]

The Playlist sometimes wants to talk to the VisualsModule only, which it does on a pipe named the same as the VisualsModule.NAME.

Does it make dependencies between VisualsModule and PlaylistModule? I thought modules should know nothing about other modules.

Mariush T.
http://mariusht.com/blog/

[serka]

I think of using a pipe with the same name as VisualsModule.NAME as a convenience to the developer. It's easy to remember what it's for in the context of the project.

Another way to see it is that PlaylistModule has a set of output pipes that are part of its API. What modules are at the receiving end of the pipe are completely up to the shell when it does the plumbing. If PlaylistModule were to be reused in another project, it could use PlaylistModule.VISUALS_OUT_PIPE as the name of its end of the pipe.

[puremvc]

Does it make dependencies between VisualsModule and PlaylistModule? I thought modules should know nothing about other modules.

It means the PlaylistModule gets the name of the pipe it wants to talk to from a static constant defined on the VisualsModule. This is technically a dependency, but an easily refactorable one. That pipename could be moved to a common constants file.

The other (seemingly) dependency is on the protocol, not the actual module. It expects the Module on the other end of the pipe to accept certain messages and to send certain messages back to it in response. (i.e. EXPORT_VIEW, VIEW_EXPORTED ).

-=Cliff>