Why use pipes vs a bidirectional core router?

[jasonengr]

I know this is probably a pretty obvious answer because I am missing something, but why would one use a pipes implementation rather than bidirectional notes directly to the core?  The premise fascinates me but from my initial understanding seems to be more complicated than needed in most application structures.  I could see it being very powerful in a case where you want to process in going and out going messages very differently, but how often do you see that?  I have only worked on one pipes project, so it would be interesting to understand how this might be useful in other situations. 

I see 4 usual cases, module talks with core, module talks with specific other module, module broadcasts to other modules, and core broadcasts to module.  It would seem simple to create an architecture that used the core as the router, having system level notifications versus core level notifications without worrying about tee splits going in and out.

I suppose multicast messaging, where you need a subset of all the modules to receive a message would be a good case for pipes, though I would only see this to be very valuable over broadcast in systems with a large amount of modules.

Thanks,

-Jason

[puremvc]

Well, if you use notifications directly into a core, you violate the encapsulation of that core by 'reaching in' and accessing its Facade in order to send the notification. Secondly, you have a problem of securing the namespace of the notification names. The cores must at a minimum share a constants file that defines the constants used by each core. This makes it very difficult to build a system where third parties can create modules that work with your app, since you don't really control their notification namespace. Also, in such a system, it's pretty desirable to have customized payloads.

Just imagine you're building a system where you don't control the implementation of the modules at all. The only thing you can do to control the protocol completely is to create custom classes which can have typed payloads, and define their own message names. That's what Pipe Messages do.

It's modeled after Unix, where there are many independently-created 'modules'; commands which have at a minimum standard input, output and error pipes. They deal mostly with text streams, but you get the picture. Nothing ever reaches into command and twiddles its guts to communicate with it, you just feed it on its STDIN and listen on STDOUT/STDERR.

-=Cliff>

[jasonengr]

Cliff,

Again definitely appreciate the responses.  I think my last post might have been a bit confusing in what I was trying to get across.  I was using the word core instead of kernel.  I suppose I am thinking of a system as follows:

[kernel] [1]<---->

• [modules]

1 kernel to many modules, generally the modules would work on their own name spaces.  If a module needed to talk to another module, it would dispatch a message to the kernel which would then forward it to all modules.  So system level messages vs module level messages.  I suppose a system such as this could be implemented on top of pipes, though with the tee splits you would have no need to have the kernel in between the module to module notifications.  I suppose pipes is more robust than an implementation like this because it allows modules to create their own tree structure and possibly internal pipe loops, like multistage filters.

I can understand pipes in the context of passing the output of one application to the input of another application and so on.  Very useful if you want to filter messages through another module before it actually gets to the kernel, or if you don't want to bother any other modules and just pass the output to the input of that module.

I guess my question: Is there a lot of applications that use a different tree structure model than the kernel and many cores for a multi core implementation?  Is there a lot of architectures that call for in messages and out messages to be processed by different modules? Usual scenarios I can see for a typical application:

1. Module asks Kernel for something (possibly to application config, or possibly reposition the module)
2. Module tells another module(s) to do something (possibly display a new view with the message data)
3. Kernel tells module(s) to do something (possibly refresh)

Again, appreciate the response, just trying to familiarize myself more with the reasoning for when and why I would use pipes and process input and output differently. Or is this just a design choice (as bidirectional setups can be built on this).

Thanks,

-Jason

[puremvc]

Well, it's really about creating a protocol for inter-core communication. Pipes and messages are away to configure, perhaps dynamically the relationships between cores. Messages are a way of encoding a protocol. There are plenty of ways you might do something like this, but the Pipes utility is fully unit tested, and there's even a whole other framework built upon it (Fabrication).

So, it's really just a question of home-brewing a solution or making use of one that's known to work.

-=Cliff>