Argh... I've just seen/remember that Cliff already gives an answer to a similar approach in the past:

The problem is that you can't guarantee that notification constants aren't in conflict across modules. Particularly in a situation where third-party modules are provided. A core's message space is its own. That' why pipes has a message facility that can pass between modules safely.

So I have to make sure that a notification constant is unambiguous across all cores!
Are there any other concerns?

Thanks,
Olaf

Hi,
I just stumbled over an old question wich probably was already discussed in the past.

However, from the shell I'd like to inform all "registered" cores with the same information and wonder if it has any drawbacks
to just loop over the core instances and call the sendNotification() method of their particular facades:

E.g. we could have a "cors getter" inside the shell facade to make the core instances accessible and a command "NotifyCores" that resides in the shell:

ShellFacade.as:

:

public class ApplicationFacade extends Facade
{
        ...

/**
        * Make cores accessible
        */
public function get cors():Array {
   return instanceMap;
        }
}

NotifyCoresCommand.as:

:

public class NotifyCoresCommand extends SimpleCommand
{
override public function execute(note:INotification):void {
                // E.g. use the "type" property to pass the notification name
                var type:String = note.getType();
                
for each(var core:IFacade in ApplicationFacade(facade).cors) {
core.sendNotification(type, note.getBody() );
}
}
}

This would make the "shell->cores" communication very easy without involving the view using interfaces or using the pipes utility.
The only thing that the shell and the other cores has to share would be the note name (Like the "message" in the pipes utility, if I remember it correctly).

Are there any concers with this approach?

Thanks,
Olaf

Thanks Olaf. For a few years I filled all my extra minutes writing a novel. When I got that out the door, I also found myself executing a transition to HTML5, and figured it was time for me to do something about this ancient site. I'll also be taking a more active role with the JavaScript port now as well.

Cheers,
-=Cliff>

Sorry for not providing the "Undo Multicore" version until now.
As soon as I'm finished the work on a "Undo Multicore" demo I'll do a pull request for the lib.

Olaf

Very nice! Simple and clean as the framework itself ;-)
Thanks for keeping up the great work on PureMVC Cliff.

Olaf

Hey Saad,

Just received the following email from William Rena at Arcanys Inc.:

Hi guys. You are doing great with your PureMVC Framework. I used this when I was in Flash Development. I"m a great fan with this framework especially the new PureMVC Swift. I'm currently exploring and learning to adapt this framework and use it in our team. Do you have an example how to use the Pipes and State Machine in Swift?

Do you have any code or notes up your sleeve on this subject?

Cheers,
-=Cliff>

Thanks Cliff. I'll go for the broadcast option, but surely listSubscriptions gives another perspective on inter-module communication

I think the broadcast option is best, since you never know what coordination patterns may be needed between various modules when a hash change occurs. And by trying to put all the knowledge in the shell about what modules need to respond to what hashes, you sort of defeat the encapsulation of a modular system.

You could, of course have each module, upon connection, or in response to a broadcast pipe message, respond with a list of 'subscriptions'. So that the shell is then able to realize on a given hash change which modules to send the message to.

Cheers,
-=Cliff>

Hi Cliff,

Building on the same thread but consider the scenario on the server-side for the node.js environment with several modules plumbed to the Shell and I quote

sends pipe message on a STDOUT pipe to all plumbed modules. That message would pass the hash fragment to the modules, and any that need to respond may do so.

Will this be considered inefficient if each requestVO (request/response) is broadcast to all modules while knowing that only one will handle it. Although with this strategy I can connect a Filter to each module's Junction's STDIN and check for URL segment (/customer, /product) before I let it in to respond and fulfill the GET/POST request.

The other strategy is to determine the destination within the shell in a Command, then send Notification (body: requestVO type: pipeName) followed by JunctionMediator's writing to a specific named Pipe. (Con: possibly will have too many checks/branches based on number of modules)

Personally I'd like to go for the broadcast option, please advise.

I would say clone the repo with the standard version and add a multicore tree. You should be able to temporarily change the library project settings to point to the muliticore sources and compile a swc. As I recall that was the way i had to do the statemachine swcs.