PureMVC Architects Lounge

This utility provides the capability for creating pipelines that pass messages between Cores in a PureMVC AS3 MultiCore-based application. Pipelines can be composed of filters, queues, splitting and merging tees, and more.

The demo has historically been located here: http://trac.puremvc.org/Utility_AS3_MultiCore_Pipes
The project has been moved here: https://github.com/PureMVC/puremvc-as3-util-pipes/wiki

The author is Cliff Hall.

Exciting stuff Cliff, THANKS!!  It's always great to see a knowledgeable architect at work ;)

Thank you very much!

Been working out the details of an application that will take advantage of multicore and this is something we've been struggling to deal with

Glad to hear there will be some eyeballs on this to make sure it ends up doing the right thing.

Unit tests are being built today and I hope to be on the way to having a demo posted by tommorow or day after.

Cheers,
-=Cliff>

The plumping metaphor is awesome. It was instantly clear. Nice work.

This was the missing piece in my multi-core legos.

Hi,

Any word on the pipes demo?

Thanks

I've worked through a simple example to understand this utility. Below I illustrate how to use a junction together with two cores that have a pipe listener to receive messages and a pipe for sending messages.

Conceptually, it took awhile to understand that a pipe used to send message out of a core, is from the junction's perspective coming in. 

For simplicity, I kept all the code in a single MXML file. Next, I will next need to split up code between two child cores and a main core that creates the junction and is aware of the pipes that each core has.

<?xml version="1.0"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[

import org.puremvc.as3.multicore.utilities.pipes.interfaces.IPipeMessage;
import org.puremvc.as3.multicore.utilities.pipes.messages.Message;
import org.puremvc.as3.multicore.utilities.pipes.plumbing.Junction;
import org.puremvc.as3.multicore.utilities.pipes.plumbing.Pipe;
import org.puremvc.as3.multicore.utilities.pipes.plumbing.PipeListener;


                        private var j:Junction = new Junction();

public function pipeTest():void
{

// Each Core has listeners to receive messages
// Each Core has pipes to send messages
var coreA:PipeListener = new PipeListener( this, coreAGotMessage );
var coreAoutpipe:Pipe = new Pipe();

var coreB:PipeListener = new PipeListener( this, coreBGotMessage );
var coreBoutpipe:Pipe = new Pipe();

// MXML is aware of the pipes coming out of each core and into the junction
                                // declared outside of coreA/coreB
trace( 'Junction.registerJunctionInPipe', j.registerPipe( 'fromCoreA',  Junction.INPUT, coreAoutpipe ));
trace( 'Junction.registerJunctionInPipe', j.registerPipe( 'fromCoreB',  Junction.INPUT, coreBoutpipe ));

// MXML is aware of the pipes going into each core and out of the junction
                                // declared outside of coreA/coreB
trace( 'Junction.registerJunctionOutPipe', j.registerPipe( 'toCoreA',  Junction.OUTPUT, coreA ));
trace( 'Junction.registerJunctionOutPipe', j.registerPipe( 'toCoreB',  Junction.OUTPUT, coreB ));

j.addPipeListener( 'fromCoreA', this, onMessageFromCoreA );
j.addPipeListener( 'fromCoreB', this, onMessageFromCoreB );

// Core B has an outpipe and sends a message via this pipe
coreBoutpipe.write( new Message( 'Hello from core B' ) );

// Core A has an outpipe and sends a message via this pipe
coreAoutpipe.write( new Message( 'Hello from core A' ) );
}

// MXML handles messages on a pipe and writes them to another pipe
private function onMessageFromCoreA( msg:IPipeMessage ):void
{
j.sendMessage( 'toCoreB', msg );
}

private function onMessageFromCoreB( msg:IPipeMessage ):void
{
j.sendMessage( 'toCoreA', msg );
}

/**
* CoreA implements this message handler
* @param msg
*/
private function coreAGotMessage( msg:IPipeMessage ):void
{
trace( 'Core A got message', msg.getType() );
}

/**
* CoreB implements this message handler
* @param msg
*/
private function coreBGotMessage( msg:IPipeMessage ):void
{
trace( 'Core B got message', msg.getType() );
}
]]>
</mx:Script>
<mx:Button label="SendMessages" click="pipeTest()"/>
</mx:Application>



This link doesnt work  :'(

Still working on a demo. Will post soon, likely something today.

-=Cliff>

I'm working in AS3, using a extended MovieClips to kick off each facade (core).  My Shell is also a MovieClip.  Would I implement Pipes in my applications' facades, or in the main class?  Also, would my Shell take on a different role than my cores (would it manage all the Pipes stuff)?

The approach I'm taking in the demo is that the Module must implement a 'IPipeAware' interface. This is part of the demo, not the utility though it might go into the utility if it proves to be the best way of doing things.

The Module has to expose 'acceptInputPipe' and 'acceptOutputPipe' methods. It also keeps a reference to its ApplicationFacade so it can send Notifications. It could use events and talk to a Mediator for the Module itself (akin to an Application talking to an ApplicationMediator), but the Module in this case will not have a graphical basis itself. It will create any graphical assets it needs to have displayed and send those assets to the shell by way of a pipe if it needs to. Perhaps in response to a message send from the shell.

So, the Shell or main app will be in charge of the display space and what gets to be displayed where. Modules may offer up UI components to be attached to the view hierarchy owned by the app. It will also be in charge of assembling the pipes and connecting the modules to the proper ends by calling the IPipeAware methods on the Modules it's managing.

Inside a module, a JunctionMediator is registered at startup with a new Junction instance. When the Module has its 'acceptInputPipe' or 'acceptOutputPipe' method called, it sends off an ACCEPT_INPUT_PIPE or ACCEPT_OUTPUT_PIPE Notification, with the Notification body being the pipe and the Notification type being the name.

The JunctionMediator has listed these as Notification interests. In responding to both these Notifications, it registers the new pipe with the Junction. If its an INPUT pipe, it further calls the Junction's addPipeListener method setting itself as the context and its handlePipeMessage method as the callback.

The JunctionMediator wants to also be interested in internal notifications that need to be turned into messages and sent out a given output pipe. As well, in its handlePipeMessage method, it handles pipe messages using a switch/case construct just like handleNotification. Most incoming pipe messages will be turned into a Notification to be handled by other parts of the app.

So JunctionMediator doesn't need much logic in it about how to deal with a given message other than how to convert it to the right Notification internally, though in a simple module, it might access a Proxy to store data or perhaps retrieve it and send it right back out an output pipe in the form of another message.

-=Cliff>

Thanks for that write up, it gives a lot of direction on how one might apply the pipes utility. I was completely thinking of this from another perspective, that is, implementing a PipeProxy or JunctionProxy to read and write data services to and from a core, similar to how one would communicate with a web service.

Some of my cores don't have a proper view, however, I can see that the flexibility of a mediator's behavior to both send and express interest in notifications is valuable.

Would you recommend that it is best to communicate via pipes at the mediator level per your example?

Your earlier message with the code isn't quite right, I think you have it backward.

At a core's Junction, input pipes are as you would expect; the pipes messages come in on. Output pipes are for outgoing messages leaving the core.

Using the junction to declare pipe direction let's us be sure that when we use the junction's sendMessage method that we've specified an output pipe. And when we us the junction's addPipeListener method, it makes sure we're trying to listen to an input pipe.

So we probably won't do a lot of manual PipeListeners or pipe.write()s. Instead we'll use the junction methods for that.

The shell may assemble a pipeline then inject it into the module by an acceptInputPipe or acceptOutputPipe methods, then the module in charge of listening ot sending via the junction.

The shell might construct a pipe and inject it as an input pipe for one module and an output pipe for another. If they need two way communication it'll also do the same in the reverse direction with another pipeline.

-=Cliff>

And I did have it backwards. When reading the AS docs I couldn't quite figure out where junctions are managed, in the core or outside of it. I started to get confused and used up half a yellow scratch pad, while writing up some test code. Your comments help a lot.

Still curious to hear your opinion of using junctions in a proxy though...

Here's a use case to help illustrate. Suppose I have a core which models chemical reactions via calculations and data structures. This 'chemical core' needs to talk with two other cores:

• A 'database core' provides chemical and reaction information.
• A 'view core' handles the graphical display of the data structures found in the 'chemical core', (is it a blue boiling liquid, or gaseous toxic green vapor)

In this use case a JunctionProxy handles communication with the database core and a JunctionMediator handles communication with teh 'view core'.

Is the aim of the pipes utility to be used for every inter-module comunication, that is, between sibling modules and between app shell and child modules? Is is supposed to be sort of a standard interface for communicating between cores no matter what kind of task those cores perform, or is it more aimed at communication between sibling modules only (i.e. not the core running the shell app)?

Yes, it is meant to be used by any core to talk to any other core. Shell to module or module to module, they're all 'cores' to PureMVC.

As to Proxies handling the junction, we must be able to send and receive messages and act in a mediation role betweeen the junction and the rest of the app. So a Mediator is more appropriate than a Proxy even if the module we send messages to is a 'database' module.

Have a look now at the PipeWorks MultiCore demo just posted.

-=Cliff>   

I see in the demo that mx.modules.ModuleBase is used in the PipeAwareModule.  I assume extending MovieClip would be OK for Flash AS3 modular apps?

Consider the Main App/Shell a core as well. And pipes connect all sorts of Cores in whatever configuration is necessary. See in the PipeWorks demo how the LoggerModule, the PrattlerModule and the Shell all have JunctionMediator subclasses that let them communicate with everything else.

Of course to connect two sibling modules without them having a reference to each other (thus defeating the point), a 'higher power' which has a reference to them both. this means the Shell will probably coordinate the activity of connecting the pipes from itself to various modules and between various modules.

-=Cliff>

I get the idea of a shell being on the same level as any other core, etc, and managing messages between cores, but specifically in the case of PipeAwareModule (org.puremvc.as3.multicore.demos.flex.pipeworks.common) -- I assume there's nothing tying this to the use of mx.modules.* -- that is, I can have my PipeAwareModule extend MovieClip instead of Module, right?

I suppose my overall question is can I do the same thing in without Flex or the Flex framework?  This will be an important distinction for those of us using Flash only.  In my case, I need to be sure this is the reality before I move forward with a really large codebase using Pipes.

Sorry about that last post looking like I wasn't listening to you. I was on my cell phone and didn't see it was on an extra 'page' of the thread.

You can totally do the PipeAwareModule thing without using mx.* Use MovieClip if you want, not a problem.

I based PipeAwareModule in the demo on ModuleBase because I'm working on a job using them and I wanted to make sure that the use of the framework, the pipes utility and Flex Modules were all demonstrated to work properly together.

I'm going to have to noodle a bit on how to pull some of the stuff in that demo out into utiilites in their own right.

-=Cliff>

Hi Folks,

Please note, the PipeWorks demo has changed and so has the Pipes Utility. The IPipeAware interface and JunctionMediator have been refactored into the utility itself.

-=Cliff>

One thing I've been noodling about is how to deal with the complexity of managing the message types between cores as the number of specialized cores increases. I currently have 6 cores which are loaded depending upon the privileges of the user.

First we created a class that extends the Message class for each core. However, some cores need to turn around and send a response message, which means that the junction mediator of each core would have to know about several message classes and this quickly got confusing. Instead we're making heavy use of a class that also extends the Message and adds a destination to the header. The destination is also used as the name of dediated core  pipes.

Some of the cores connect to asynchronous web services and when a result is returned in response to query message, we can either send the result with the query response or just notify that data arrived and then implement a robust API for each core.

Sounds like you're getting the hang of it. Thanks for reporting in with these sort of thoughts.

The MultiCore+Pipes environment is really powerful, but but you really have some multi-level architecture considerations now. And the sooner the patterns and anti-patterns are uncovered the better!

-=Cliff>

My context is a multi-module application, and instead of removing modules, I cache them and simply add or remove them from the display hierarchy. I never unload the PMVC cores.

IPipeAware modules have accept* methods but not corresponding remove* methods. When a module is unloaded, I would like to remove the plumbing. I understand that I could just leave the plumbing active and test whether or not it should receive messages, but I would have preferred to remove and re-add plumbing as needed.

I tried re-adding plumbing when a module was activated, which didn't error, but when I attempted to send a message the Pipe class RTE'd with a null output. It seems like there should be a clean way to remove any plumbing associated with a loaded module. I also feel like I may be overlooking something, or mis-implementing Pipes altogether.

I have what I feel to be a very clean and vanilla implementation of MultiCore and Pipes otherwise, and I'd love to release it to the community as a demo. Cliff, what is the best way to get this to you for your review? I think many could benefit from this.

...another thing that I felt was appropriate was using a ModuleProxy in the main application, versus storing modules in a Mediator, which it seems that every other demo does. In reality, loaded modules are part of the model, and their interaction with the user (that is, being added to the display hierarchy) alone is a view element. I'd love to get some feedback on this.

Also, I've included the app structure below which gives you the basic idea of what I'm trying to accomplish:

(http://lukesh.com/files/adeptiv01.png)

Modules are typically used to compose the UI. How does one construe that as having something to do with the Model? Just because they may be loaded dynamically doesn't make them a part of the domain model.

Even if the module extends ModuleBase and is not directly addable to the display hierarchy, but creates and exports components that will, it is still a View tier object.

-=Cliff>   

Cliff, I see the point you are making, however my rationale was:

1. Modules do not necessarily need to be part of the display hierarchy, interact with the user, or create and export visual components (i.e. the view).

2. The list of loaded modules can be articulated in different ways in the view tier. For example, let's say that I had a module container that displayed the actual module, and another control that showed a button for each loaded module (both view components, both with their own Mediators). The ModuleProxy maintains an array of loaded modules and sends notifications indicating that the module is loaded and ready. Any Mediator observing can then articulate that as they need to, either by actually adding the module to the display hierarchy, or by simply creating a button.

Does this make sense?

I too have Adapter modules that do nothing but talk to services. But most modules end up composing the UI so I consider them marginally more apropos to the View tier. Its hard to think of a swf file as data. It is application code. The Model tier is about representing the domain - the data the system manipulates.

Plus, since mediators can listen for notifications it cuts down on commands.
 
-=Cliff>

Actually, then would you recommend architecting the system with as few commands as possible? My biggest issue with PMVC is that notifications can be handled in more than once place / methodology, and it seems to make app logic harder to follow. Not sure if you got my PM, but the sample app is here:

http://lukesh.com/files/AdeptivPMVC.zip (http://lukesh.com/files/AdeptivPMVC.zip)

I'd really appreciate feedback.

I love that PMVC is so flexible, language agnostic, etc... but sometimes it feels like it gives you more rope than you need, and definitely enough to hang yourself with. I'm just trying to get a decent meta-meta-framework :) that will guide our development team for backend-y Flex apps.

I'll get a look at this as soon as possible. I'll be travelling tommorow and may not get the chance until I return late next week.

-=Cliff>

The module proxy is going through all the motions of loading the modules and I'm sure it works fine, but as I said before, I consider modules view components and have a view-tier class that loads and manages the modules with a mediator controlling access to it. Modules are swf files and not data, therefore, IMHO, they do not belong in the Model domain. This is just my take on it.

That said, if this makes sense to you feel free to use it. In the end it's about what works while still maintaining separation of concerns in your code. People often use proxies to load other assets provided to the view like images. Even though view tier assets are not really model data, the aggregation of anything that talks to the server living in a Proxy is a strong argument for breaking the conceptual separation of what is and isn't actual domain model data.

As for refactoring to reduce the use of commands, and of multiple places to listen for notifications, if a command isn't registered for a given notification, then it should be clear that it must be an interest of some Mediator. I agree that tracking down which one(s) can be a pain, and what I sometimes do to combat this is to add a short comment to the definition of the constant saying which mediator or command is interested.

-=Cliff>

hi! im finding trouble in creating the multicore mvc pipes structure in flash as3 only...
can you help me..
do you have a sample as3 sample program that we could see..with no flex..
we would really appreciate it..

hi! im finding trouble in creating the multicore mvc pipes structure in flash as3 only...
can you help me..
do you have a sample as3 sample program that we could see..with no flex..
we would really appreciate it..

I don't believe there is any demo for as3. I have managed to work it out on my own, but my project is a bit complex to just post as an example. I can try to help explain things though if you let me know where you are having trouble. I'll mention that there's actually very little difference between the Flex Multi-core pipes examples and a pure AS3 one since most of the action takes place within PMVC itself and thus has no direct ties to Flex.

The one thing you will need to build is a Module Loader, like Flex, using the Loader class. Here's mine in raw form;
/**
* ...
* @author Jason MacDonald (Jason.MacDonald@vfmii.com)
*/
public class ModuleLoader extends Sprite{

public static const READY:String = "READY";
private var _module:ILoadableModule;
public var _moduleVo:LoadableModuleVo;

public function ModuleLoader() {

}

public function load(moduleVo:LoadableModuleVo):void {
var loader:Loader = new Loader();
_moduleVo = moduleVo;
loader.contentLoaderInfo.addEventListener(Event.COMPLETE,onLoaded);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR,onIOError);
loader.contentLoaderInfo.addEventListener(ProgressEvent.PROGRESS,onProgress);
var loaderContext:LoaderContext = new LoaderContext(true);
loader.load(new URLRequest(moduleVo.url), loaderContext);
}

protected function removeListeners(loader:LoaderInfo):void {
loader.removeEventListener(Event.COMPLETE,onLoaded);
loader.removeEventListener(IOErrorEvent.IO_ERROR,onIOError);
loader.removeEventListener(ProgressEvent.PROGRESS,onProgress);
}

protected function onLoaded(event:Event):void {
var loaderInfo:LoaderInfo = event.target as LoaderInfo;
_module = loaderInfo.content as ILoadableModule;
removeListeners(loaderInfo);
dispatchEvent(new Event(READY));
}


protected function onIOError(event:IOErrorEvent):void {
//do something
}

protected function onProgress(event:Event):void {
//do something
}

public function get moduleVo():LoadableModuleVo {
return _moduleVo;
}

public function set moduleVo( value:LoadableModuleVo ):void {
_moduleVo = value;
}

public function get module():ILoadableModule {
return _module;
}

public function set module( value:ILoadableModule ):void {
_module = value;
}
}
LoadableModuleVo is just
/**
* ...
* @author Jason MacDonald (Jason.MacDonald@vfmii.com)
*/
public class LoadableModuleVo {

private var _name:String;
private var _url:String;
private var _version:String;

public function LoadableModuleVo() {

}


public function get name():String {
return _name;
}

public function set name( value:String ):void {
_name = value;
}

public function get url():String {
return _url;
}

public function set url( value:String ):void {
_url = value;
}

public function get version():String {
return _version;
}

public function set version( value:String ):void {
_version = value;
}
}
And ILoadableModule
/**
* The interface definition for a loadable Module.
*
* <P>The only requirement of our [dynamically] loadable
* module is that it implements this interface so we can get
         * a unique ID back from the module</P>
*/

public interface ILoadableModule
{
function getID():String;

}
I use this in conjunction with a ModuleLoaderProxy and LoadModuleCommand. Note that I do not store anything in the proxy concerning the module, it simply acts as the go-between with the loader and the responder (itself). It then dispatches a notification that the module has loaded, using the loaded swf as its body for the rest of my app to listen for and act upon. This might not be the best solution, but it seemed to me the best place for service calls like this was in a proxy, but to let the mediator store the swf once it's loaded so the proxy forgets all about it after it has sent the notification.


This is  the proxy I use

    public class ModuleLoaderProxy extends Proxy implements IProxy {

public static const LOAD_MODULE:String = 'mlLoadModule';
public static const UNLOAD_MODULE:String = 'mlUnloadModule';
public static const MODULE_LOADED:String = 'mlModuleLoaded';
public static const MODULE_FAILED:String = 'mlModuleFailed';
public static const MODULE_PROGRESS:String = 'mlModuleProgress';


        public static const NAME:String = "ModuleLoaderProxy";

        /** Constructor **/
        public function ModuleLoaderProxy(data:Object = null){
            super (NAME, data);
        }

public function loadModule(moduleVo:LoadableModuleVo):void {
var loader:ModuleLoader = new ModuleLoader();
loader.addEventListener(ModuleLoader.READY, onLoaded);
loader.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
loader.load(moduleVo);
}

protected function onLoaded(event:Event):void {
var moduleLoader:ModuleLoader = event.target as ModuleLoader;
var module:ILoadableModule = moduleLoader.module;
var moduleVo:LoadableModuleVo = moduleLoader.moduleVo;

sendNotification(MODULE_LOADED, module, moduleVo.name);
removeListeners(moduleLoader);
}

protected function onIOError(event:IOErrorEvent):void {
var moduleLoader:ModuleLoader = event.target as ModuleLoader;
var module:ILoadableModule = moduleLoader.module;
sendNotification(MODULE_FAILED, module, event.text);
removeListeners(moduleLoader);
}

protected function removeListeners(moduleLoader:ModuleLoader):void {
moduleLoader.removeEventListener(ModuleLoader.READY, onLoaded);
moduleLoader.removeEventListener(IOErrorEvent.IO_ERROR, onIOError);
}

protected function onProgress(event:Event):void {
//sendNotification(MODULE_PROGRESS, module);
}


i have read your message Mr. jasonmac...
and I'm very grateful to your reply...
it help a lot..
we understand your idea of loading swf modules...
but we have a problem understanding the last part where you use ModuleLoaderProxy?
you already have two loader classes...
sorry..we find it hard to grasp your idea in using this class..

and if its not much trouble to you..
you didn't use pipes in this code...
thought this is already helpful..
i wish you can help us using "PIPES" in mvc multicore...

many thanks to you bro!

The first class is a ModuleLoader "Component" (like the Flex SWFLoader), which the proxy uses to load the swf modules and then discard them after they return. The next time a module is loaded a new ModuleLoader class (component) is created. It just allows me to use the same ModuleLoader Class in other projects/areas since it has no ties to PMVC, unlike the proxy which basically proxies the calls through to the ModuleLoader and is able to listen and respond using PMVC specific notifications.

As I mentioned earlier, the process of adding and using pipes is identical to the Flex examples once you have the swf modules loaded. Make a ModuleMediator and have it lay the pipes (or send a message to your shell to lay them, up to you) whenever a notification is received of a new module being loaded. You can see this process, minus the dynamic modules, in the PipeWorks demo.

NOTE: I only quickly cut out portions of my classes to give as a guide, they are missing other parts that weren't quite relevant to what I was trying to explain so I wouldn't use them directly :)

I'm confused...
anybody have a sample on mvc multicore pipes as3 only..

i don't know how to apply this in as3 (no flex)..

i hope somebody can show a sample code for multicore pipes..
or any alternative...

I try to cover the difference in this thread. http://forums.puremvc.org/index.php?topic=457.msg3379#msg3379

There's no difference in using Pipes between Flex and Flash, the only difference is how you load modules since there is no Module class in as3. I gave a very simple example in the thread above on how to implement a module loader in as3. You might also look at the new Fabrication utility from Darshan  http://forums.puremvc.org/index.php?topic=681.0;topicseen since it covers the loading of modules AND applying pipes I believe.

There's also a new StateMachine Utility which us AS3 only guys might want to keep an eye on. http://forums.puremvc.org/index.php?topic=739.0

Thanks a lot jasonmac...

your really a big help...
we already make your code work.. :)

I'm working on a PureMVC/Pipes project (both of which I ported down to AS2) and I'm unsure of the best way to pass data in to a module.

I have my main app, which has a UserVO object representing the user. I have a module with a bunch of self-contained logic that performs configuration operations on the userVO, and then passes it back to the main app.

I have gotten as far as getting the module to load and connect up with the main app via pipes, and I can send a message from one to the other.

How should I pass in the UserVO to the module? It seems like I should send it in via a Message--after the module loads and is connected, send it from the main app's JunctionMediator. But I think I don't get the Message yet. It seems like it is supposed to be a wrapper for a Notification--does it have to be? Is there any problem in just passing the UserVO as the body of a Message, and have the module's JunctionMediator create the notification and send it along from there?

Any help you can offer will be greatly appreciated!

No problem at all.

The message name if constructed properly provides you with a unique string that you can also reuse as a notification name within your module. Your JunctionMediator can simply package the message inside the body of a notification with the same name and send it. Commands and Mediators can then do whatever they need to with the message.

This process is message tunnelling. Its useful if the message itself has a lot of properties that will be used at the recipient, such as a Command. No need to pluck all the values off the message at the receiving JunctionMediator before passing it on into the app where those values are used. This way, the Message subclass also acts as a VO. Put typed getters and setters on it that access properties you add to the message header.

The other possibility is put a VO into a Message body, send it, and at the receiving JunctionMediator, pluck out the VO, and send it in the body of a note with the same name.

-=Cliff> 

Thanks for such a wonderfull util lib. I'm realy anjoying it's simplicity and understandability.

Two question have appeared when playing with pipes:

1. Messages are most likely relative to data part of an application, rather than to it's view. And generally mediators in PureMVC are used to mediate between "flash" view components and "flash-less" core. So why junction mediator? Why not some sort of junction proxy? Though I can understand that mediator pattern is more general than it's commonly used in PureMVC.

2. There is an already done (thanks for helping lazy coders) method in JunctionMediator

public function handlePipeMessage( message:IPipeMessage ):void
{
}

For me it's a bit strange why it's public. The only thing I can guess why it's public - it can serve as a usual function, rather than just pipe listener. Thus we can make some custom message inside module core and pass it to that. But the method is specificaly made only for pipe listening. I'd make it protected for sure.

3. Sorry for my english :)

1. A) Mediators can be sent notifications which makes it easy to get messages sent. B) the Model has no concern with messages being bassed between cores in an app, which are generally view related anyway.

2. You're right, handlePipeMessage should be protected.

3. I bet I'm worse at your language than you are at english :)

-=Cliff>

Hi all,

I'm trying to get something working in Flash with Pipes, but I'm really struggling here. I really want it to work but I'm probably just too dumb!  ???

Anyway I've tried to connect a module to a shell using acceptOutputPipe and acceptInputPipe. I am then calling sendMessage with the body of the message just being "Hello"... But then it just crashes on the Pipe.write command because output is supposedly null...

Cliff you don't fancy doing another one of your fab seminars in London any time soon do you?  ;)

Okay sorry about that outburst... I realised I'd added too many pipes!  ;D I'd added the teeSplit and Merge to the module as well as the shell. I removed them and it started working.

One thing I'd like to know a bit more about is the format of a Message, namely what the header and priority properties actually do... Is there any documentation on these?

I am getting to grips, slowly but surely!

 ;)

Yes, there is API  documentation of the Message class and all the other classes in the Pipes utility on the Pipes Utility project menu. tou can see an example of the Message class header being used in the LogMessage subclass in the PipeWorks demo. Priority is used by the Queue class which can be used to hold the messages coming down a pipeline until you flush the queue. Before flushing, you can have the Queue set to sort messages by priority. This functionality isn't used in any demos, but is fully exercised in the Pipes Utility unit tests, which are the ultimate place to go to understand Pipes, since each functional par is tested in isolation with plenty of assertions about expected behavior. Much easier than trying to sort it out of a big demo.
 
-=Cliff>

First off, thank you Cliff for PureMVC and Pipes, I think it's fantastic.

I am doing a module based app written in AIR and Flash/AS3, using the Multicore PureMVC and Pipes. There is a shell which loads and unloads modules. Only one module is loaded at a time, designed to simulate navigating from one module to another.

My question regards the unloading of modules and memory. As I'm running the "finished" AIR app, I've got the Activity Monitor open. I load and unload modules, and watch the memory usage increase until it reaches a plateau. The more (individual) modules I load and unload, the higher the memory plateau reaches.

Each module in itself is properly cleaned up after unloading - I have tested this by repeat loading / unloading the same module, with no memory increase. What seems to happen is that each module I load is kept in memory, seemingly out of my control.

What I had wanted to do was free the memory of all but the shell & loaded module. As you can imagine, if each module has a memory overhead of 20-30MB (Activity Monitor / "Real Memory"), there only need be a few modules loaded and unloaded before the memory usage becomes an issue.

Is there a solution for this? Am I missing something?

Thank you kindly for any feedback,
Dan

There is an excellent tutorial about garbage collection and pipes written by Simon Bailey. You'll find a like to it on the menu on the Pipes utility's Trac site. He has shown that it is completely possible to manage loading and unloading of modules using pipes without accumulating memory overhead. Searche these forums for pipes +GC and you'll find a recent post by me, exaustively covering this topic.

-=Cliff>   

Any reason why we don't have such methods on IPipeAware?

function disconnectInputPipe(name:String):Void;
function disconnectOutputPipe(name:String):Void;
These would be useful when a module needs to be disconnected but still kept on the side for later reuse.
For example, one application could have a 3D rendering module and a 2D rendering module. Only one of them would need to be active, but because the user can switch between 2D and 3D at any time, it's best to keep each version of the module at hand.
Unless someone can suggest me a better approach than the above 2 methods...

IPipeAware defines the minimum necessary methods to get a module plumbed. Once the pipes are connected, you can send a message directly to the JunctionMediator in the core to tell it to disconnect a given pipe.

-=Cliff>

Hello -

Currently trying to figure out Pipes. Had one or two questions, if anyone has a moment:

1) While I think I understand the basic way the Multicore and Pipes system works, what I don't quite understand is how the Pipes objects are supposed to find each other without using the facade. (Since the facade/core system for each module exists separately from one another, correct? Without realizing that they each exist?) Could anyone explain to me how that particular part of the system works?

2) Another thing I found puzzling were the Message objects. Why are those necessary? I understand that we're adding the priority and queue system, but why not just extend the core Notification object class?

Thank you very much for your time.

what I don't quite understand is how the Pipes objects are supposed to find each other without using the facade

A core (expressed as an Application or Module in Flex) is connected to another core by Pipes.

As with actual real-world plumbing, Pipes meet at Junctions. Inside each core is a JunctionMediator that holds the Junction for the core. All the input and output Pipes for the core meet at this Junction.

The core itself should implement an interface called IPipeAware. That interface requires two methods called acceptInputPipe() and acceptOutputPipe().

The 'shell' core (the application) is typically responsible for the plumbing. That doesn't always have to be the case, it is the most logical place, since at least the first other core will have to be instantiated within the Shell's code.

With one or more IPipeAware Modules in hand, a piece of code may create Pipes and plumb the cores  easily by invoking those two interface methods. Those methods send off a notification heard by the core's JunctionMediator which takes care of attaching the Pipe to the local Junction.

Of course you can check out the PipeWorks demo which plumbs a bunch of RSS reader modules and also implements a plumbed logger:
http://trac.puremvc.org/Demo_AS3_MultiCore_Flex_PipeWorks

And for a real world example, check out the source of the Sea of Arrows custom music player app:
http://seaofarrows.com/srcview/

In the latter, start your investigation with a look at some key classes:
com.seaofarrows.musicplayer.common.view.components.PipeAwareModule
com.seaofarrows.musicplayer.modules.playlist.PlaylistModule
com.seaofarrows.musicplayer.modules.playlist.view.PlaylistJunctionMediator
com.seaofarrows.musicplayer.shell.controller.PlumbCommand

Another thing I found puzzling were the Message objects. Why are those necessary? I understand that we're adding the priority and queue system, but why not just extend the core Notification object class?

Messages and Notifications are not used in the same manner, so there really was no value in extending Notification.

Messages don't have a name property because they will always be custom classes.

You never receive a Message and then broadcast it to the rest of the core as a Notification. For the same reason we don't just retrieve a foreign Facade and send a Notification to its core, in a system using third-party Modules, you could not control the namespace of the Notification. A third-party could end up sending a Notification of the same name as something you're using in your core, and foul things up.

So it was a very explicit decision to keep Messages and Notifications separate to make their usage clear: Messages for inter-core communications, Notifications for intra-core communications.

-=Cliff>

/* The 'shell' core (the application) is typically responsible for the plumbing. That doesn't always have to be the case, it is the most logical place, since at least the first other core will have to be instantiated within the Shell's code. */

Ahhh, I see. So the main Application still has some unique responsibilities, despite the interchangeability of cores. I get it now. Thank you.

/* You never receive a Message and then broadcast it to the rest of the core as a Notification. For the same reason we don't just retrieve a foreign Facade and send a Notification to its core, in a system using third-party Modules, you could not control the namespace of the Notification. A third-party could end up sending a Notification of the same name as something you're using in your core, and foul things up. */

I see. So you coded this system so that people could exchange and use each others' modules, if need be. That makes sense, then.

Again, thank you very much for your time.

Hello, again -

So I was just wondering - about the header property you have on the Message object. What were you using that for in the project you created Pipes for? Just curious.

Thanks.

I'm not sure whether I was using it in the Sea of Arrows player or not.

The Message header is meant to carry any meta-data about the message for the recipient in the same way that email headers tell an email client extra stuff about the message, such as its character set, who the intended recipient is, who sent it, etc.

-=Cliff>

Gotcha. So did you have a particular role for it in mind, or was it just a "in case I need it" sort of thing?

It was really modeled after an email message, the parts of which make a lot of sense to me. Headers allows us to transmit 'out-of-band' information about the message without fiddling with or understanding the body.

For instance, you might have an image processing module. You send it an image in the body, but tell the core what to do with it by passing parameters in the header like this:

var header:Object = { operation:'blur', type:'gaussian', xAmount:'20', yAmount:'100' };
var body:Object = BitmapData(myImage);
var message:Message = new Message( Message.NORMAL, header, body );

Makes sense. I just thought it was an interesting choice, putting it in Pipes but not in PureMVC's Notifications. I can see, though, how that extra functionality might come into play or be useful, given how relatively complex interactions between modules might be as opposed to internal communication within an app.

So I've spent the last week digging into Pipes. I like a lot of things about it, especially in the exact control it allows you over the flow of messages between modules.

While rooting through old posts here in the forum, I also came across the LICS project (http://forums.puremvc.org/index.php?topic=1624.0) someone floated as an alternative a while back. To sum it up for the audience at home, the basic idea there is to use an observer-pattern Singleton (with a single point of contact through a Mediator or a Proxy) to pass messages back and forth between the Cores. While it technically breaks encapsulation between the modules, functionally, it should work. A coworker and I were talking over the pros and cons of each approach earlier today.

You obviously have put a great deal of thought into this issue over the years. So I was just hoping to ask your opinion. What would you see as the advantages or disadvantages of Pipes over a Singleton-based system like LICS?

What would you see as the advantages or disadvantages of Pipes over a Singleton-based system like LICS?

LICS is a simpler solution, and one you might want to use in a small application where you will control all of the cores that are used. Its only disadvantage as far as I can tell lies with potential notification namespace collisions. From the LICS home page:

In order to avoid coupling between modules, it is essential that the inter-core notification names, and any classes used to carry information between them, are kept completely separate. They should be viewed as a system level set of classes, rather than on a module by module basis.

From a framework vendor perspective, I must consider it axiomatic that a modular application may use modules written by third-party vendors. That means that the application vendor and the module vendor may (read: should) be completely unaware of each others' notification namespace and unable to disturb a core by triggering a notification that it shouldn't.

This is why Pipes uses Messages rather than Notifications. It ensures that the inter-core messaging is decoupled from the intra-core messaging. It allows us to expose a a core's communication protocol as a set of custom message classes which can have whatever properties we want them to and to control the flow and processing of those messages based on metadata. As you pointed out, communication between cores may be more complex than the notes bouncing around inside a core.

Pipes is just one way of doing it. LICS is definitely reasonable approach as well.

-=Cliff>

LICS is a simpler solution, and one you might want to use in a small application where you will control all of the cores that are used.

Would you be at all concerned about performance issues with a Singleton-based approach? In other words, would you be worried that the Router singleton, or its equivalent, would become too massive/too cumbersome as more cores are added?

From a framework vendor perspective, I must consider it axiomatic that a modular application may use modules written by third-party vendors. That means that the application vendor and the module vendor may (read: should) be completely unaware of each others' notification namespace and unable to disturb a core by triggering a notification that it shouldn't.

This is why Pipes uses Messages rather than Notifications. It ensures that the inter-core messaging is decoupled from the intra-core messaging. It allows us to expose a a core's communication protocol as a set of custom message classes which can have whatever properties we want them to and to control the flow and processing of those messages based on metadata. As you pointed out, communication between cores may be more complex than the notes bouncing around inside a core.

I understand. Pipes has a number of features with regards to its messaging system that I could see being very useful. The ability to queue messages, for instance, since we don't know if and when a module is going to be available.

Thank you very much. I appreciate you taking the time to share your thoughts with me.

Would you be at all concerned about performance issues with a Singleton-based approach? In other words, would you be worried that the Router singleton, or its equivalent, would become too massive/too cumbersome as more cores are added?

Not unless you subclass it and add tons of functionality to it. If its responsibility is just keeping track of cores and routing messages between them, then no, I wouldn't be worried about its Singleton nature.

If you decide to play around with both Pipes and LICS, I'd be glad to hear about your experiences and impressions.

Cheers,
-=Cliff>

Hey. So I had some time over the weekend. Wound up trying to come up with a library that finds a middle ground between Pipes and LICS. (yeah, I know, yay, another standard (http://xkcd.com/927/). But I was curious to see if the two approaches could be combined somehow.)

I'm calling it CoreHub at the moment. Would be very interested to know your thoughts on it. Will start another thread in this forum so as to not hijack this discussion more than I already have. Said thread is here: http://forums.puremvc.org/index.php?topic=2018.0 (http://forums.puremvc.org/index.php?topic=2018.0)