Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1] 2 3 ... 5
Print
Author Topic: Pipes - A PureMVC AS3 MultiCore Utility  (Read 93250 times)
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« on: May 19, 2008, 02:23:20 »

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.
« Last Edit: September 23, 2012, 03:51:49 by puremvc » Logged
riafan
Courseware Beta
Jr. Member
***
Posts: 19


View Profile WWW Email
« Reply #1 on: May 19, 2008, 07:54:18 »

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

Logged
swidnikk
Courseware Beta
Jr. Member
***
Posts: 13


View Profile Email
« Reply #2 on: May 20, 2008, 12:40:18 »

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

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: May 20, 2008, 08:22:30 »

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>
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #4 on: May 24, 2008, 09:14:07 »

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

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

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
talkeetna
Newbie
*
Posts: 2


View Profile Email
« Reply #5 on: May 27, 2008, 01:01:46 »

Hi,

Any word on the pipes demo?

Thanks
Logged
swidnikk
Courseware Beta
Jr. Member
***
Posts: 13


View Profile Email
« Reply #6 on: May 27, 2008, 03:33:37 »

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>

« Last Edit: May 27, 2008, 06:21:22 by swidnikk » Logged
talkeetna
Newbie
*
Posts: 2


View Profile Email
« Reply #7 on: May 27, 2008, 03:54:44 »

This link doesnt work  :'(
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #8 on: May 27, 2008, 05:42:04 »

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

-=Cliff>
Logged
mikebritton
Full Member
***
Posts: 42


View Profile Email
« Reply #9 on: May 27, 2008, 06:59:03 »

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)?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #10 on: May 27, 2008, 10:11:20 »

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>
« Last Edit: May 27, 2008, 10:21:23 by puremvc » Logged
swidnikk
Courseware Beta
Jr. Member
***
Posts: 13


View Profile Email
« Reply #11 on: May 27, 2008, 01:51:18 »

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?
« Last Edit: May 27, 2008, 01:53:23 by swidnikk » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #12 on: May 27, 2008, 05:42:17 »

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>
Logged
swidnikk
Courseware Beta
Jr. Member
***
Posts: 13


View Profile Email
« Reply #13 on: May 28, 2008, 12:30:49 »

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

Logged
ricardokirkner
Jr. Member
**
Posts: 18


View Profile Email
« Reply #14 on: May 30, 2008, 07:39:13 »

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)?
« Last Edit: May 30, 2008, 08:52:24 by ricardokirkner » Logged
Pages: [1] 2 3 ... 5
Print