(I should add - anyone looking at the code should probably start with CoreHub.as. That's the best documented class at the moment.)

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

So CoreHub is an attempt to combine features from both Pipes and LICS into a single package. To sum it up, it uses a specialized Singleton called the CoreHub to communicate between MultiCore instances with a minimum of fuss.

Public GitHub repository and download here:
https://github.com/tinwatchman/CoreHub/

The CoreHub singleton has two methods to send messages: sendMessage and sendMessageToCore. The sendMessage method - much like sendNotification in the PureMVC facade - sends one-to-many to any currently active interested listeners, while sendMessageToCore sends a message to a single, specific Core. If that Core is not currently active - as in, if that module hasn't been loaded yet - sendMessageToCore stores the message in a queue for delivery for when the Core comes online. This allows modules to be brought up to speed on critical information immediately after being loaded.

Key points:

• Like Pipes, keeps messages between Cores distinct from internal notifications by using a different interface/class for its messages (called ICoreMessage.)
• Uses each Core's unique Multiton key to distinguish between them.
• Each Core uses or subclasses a CoreMediator object to interact with the CoreHub singleton, in much the same way Pipes uses the JunctionMediator class as its single point of contact between the messaging system and each Core. Technically, any object that implements the ICoreMediator interface can connect to the singleton. This means that modules utilizing different frameworks (or no framework at all) can still send and receive messages via CoreHub.
• Allows an easy way to tell if a module has been loaded or not through the hasCore method. CoreHub also automatically sends out messages whenever a core is added or removed from the system (of message type BaseCoreMessageType.CORE_REGISTERED and BaseCoreMessageType.CORE_REMOVED, respectively).
• Message queueing: Like Pipes, CoreHub allows messages for inactive Cores to be stored until their modules are loaded. These messages are (by default) sorted by priority. Please note that message queuing only works when using sendMessageToCore - any messages sent via the sendMessage method are (like INotifications) gone as soon as all active, interested Cores have been notified. Both queueing and queue sorting (resulting in the queues being first-in first-out) can be turned off by setting the appropriate flags on the singleton to false.

Still working on the unit tests. Comments and suggestions on the project appreciated. In particular, I'd be very interested to hear your thoughts on this, Cliff. Especially in regards to any improvements you think could be made.

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.

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 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?

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?

Does your solution provide an easy mechanism to know when your module is complete and hooked up to the framework?

Well, technically, couldn't you just use Facade.hasCore? Provided all of your modules are Multicore?

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.

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

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.