Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Welcome, Guest. Please login or register.
June 26, 2017, 01:47:01 AM
Home Help Search Login Register
News: Please DM @puremvc on Twitter to gain forum access. Spambots are why we can't have nice things.
Pages: [1]
Print
Author Topic: A New Approach to Inter-Core communication  (Read 7808 times)
conrad
Jr. Member
**
Posts: 10


View Profile
« on: January 18, 2010, 09:37:23 AM »

***** 19/01/2010: I have updated the shell, based on comments from Cliff, new shell is now attached, please read my new post for details of the changes - I think it is even cleaner and lighter now - original post is inaccurate now, but idea remains the same *****

Hi all,

I haven't posted here before, but I have been using PureMVC for well over a year now. I have delivered a lot of apps using the multicore version (large and small), and have used Pipes and Junctions on one big project.

My thoughts on Pipes and Junctions was that it was too complicated and not very PureMVC (sorry Cliff).

I tried to think of another way of doing decoupled module communication and have come up with a system that works at the facade level.

It uses the idea of 'Supervisor' and 'Supervised' facades (although a facade can be both).

A supervisor facade (of which there should be only one) is the router and uses exactly the same Observer pattern as the mediators in order to pass information.

Supervised facades have a 'listSystemNotificationInterests' and a 'handleSystemNotification' method analogous to the mediator methods with similar names.

Facade instances can then call the 'sendSystemNotification' method to send fire and forget inter module messages. There is also a SystemCommand that extends SimpleCommand and has a sendSystemNotification method.

To me this is more intuitive and PureMVC like.

I have attached to attached a project that explains this better (I hope).

The Shell app is the main one and at startup it load a logger swf (which is a puremvc core). The shell is a supervisor facade and the logger is a supervised facade. It is listening for SystemNotification.LOG messages from any other cores that load.

If you press the 'Load Module A' button, then a second module loads up that has a supervised facade. When it starts up it uses a SystemCommand to send a log notification out to the system. The logger catches this and displays the message.

What do people think of this - are there better ways to do what I have done? Is this a valid way to implement inter core communication?


Conrad
« Last Edit: January 19, 2010, 03:41:03 AM by conrad » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2870



View Profile WWW
« Reply #1 on: January 18, 2010, 04:35:18 PM »

I notice the SupervisingFacade has it's own observer notification system.  This overloads the Facade with responsibilities that fall a bit outside its realm. The Facade isn't supposed to add new functionality but rather to expose the functionality of other actors in a complex system in one place.

That said, I didn't look much further into it, but it certainly might be a functional way of doing things. Try it out a bit and see how you like it in a non-trivial project. See if it poses any problems with memory reclamation when cores are added and removed (be sure to get rid of those observers in the supervising facade).

Also, the framework I mentioned in the other discussion is moving closer to being available. See http://imajn.net for more info and to sign up for the upcoming beta program.

-=Cliff>
Logged
conrad
Jr. Member
**
Posts: 10


View Profile
« Reply #2 on: January 18, 2010, 11:49:23 PM »

Thanks Cliff,

I see your concern about adding the Observer notification system to objects registered with the supervising facade. I also particularly don't like the way in which a supervised facade finds the supervisor (and I wrote the thing :-))

However we have tried it in a small application and it was extremely easy to use, so being a pragmatist we are going with it for the moment.

I have signed up for the Imajn beta, and it sounds very interesting. Hope I get accepted.

Anyway I shall try to sort out the issues you mention and see if I can't make it a little neater.


Conrad
Logged
conrad
Jr. Member
**
Posts: 10


View Profile
« Reply #3 on: January 18, 2010, 11:54:40 PM »

Hi Cliff,

in my beta application I stated that

"In this time I have written one large modular application using it"

and I just wanted to be clear that what I meant was

"In this time I have written one large modular application using it, AND a whole host of non-modular and smaller ones"

:-)

Thanks

Conrad


Logged
conrad
Jr. Member
**
Posts: 10


View Profile
« Reply #4 on: January 19, 2010, 02:43:22 AM »

OK,

I have update the system, and made it even more PureMVC like. There are no longer two types of facade - instead there is just a base SystemFacade. This does not have responsibilities for observer-notifier work, but instead delegates it to a Supervisor. The Supervisor is a bit like View, but it deals with IWorker's instead of IMediator's. IWorker's are registered with the supervisor by any facade/module that extends SystemFacade that wants to listen to system wide notifications.

The first facade to be created that extends SystemFacade creates the single static Supervisor - this would normally be the Shell.

The IWorker's are just like IMediator's - they have names and get registered with a notification system (the Supervisor). However their job is to listen to system wide notifications and translate them into notifications that mean something to the loaded module/core.

Reworking it this way has also made it easy to create a removeWorker method, however as I cannot override removeCore, I can not make this happen automatically when the core is unloaded - the call will have to be in the code of the core itself - however this is not too bad.

Please see the latest attached Shell.zip and let me know your thoughts on this new one :-)
Logged
reduxdj
Jr. Member
**
Posts: 11


View Profile
« Reply #5 on: March 17, 2010, 12:45:54 PM »

OK, I am curious, I have had issues with pipes, where I have to send a message to know when the junctions are created and input output pipes have been connected.  I wish it could be handled in one method, when the module is ready and can interact with framework?

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

Thanks,
Patrick
Logged
tinwatchman
Jr. Member
**
Posts: 10


View Profile Email
« Reply #6 on: April 05, 2012, 11:49:27 AM »

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



View Profile WWW
« Reply #7 on: April 05, 2012, 12:21:55 PM »

Quote
Quote
OK, I am curious, I have had issues with pipes, where I have to send a message to know when the junctions are created and input output pipes have been connected.  I wish it could be handled in one method, when the module is ready and can interact with framework? Does your solution provide an easy mechanism to know when your module is complete and hooked up to the framework?
Quote
Well, technically, couldn't you just use Facade.hasCore?
This only tells you the core is there, it doesn't tell you anything about its state, e.g., readiness to communicate with other cores.

While a core might initialize itself quickly, some cores might take awhile, so logically, no matter what methodology you use to communicate between cores, you need some sort of protocol, whether it be sending a Message off down a pipe, raising an event, exposing a property, or whatever. And even after the core is initialized and ready for business, in its lifecycle, it might go through periods when it is not accepting outside input. So you may need to implement a busy/ready protocol.

-=Cliff>
Logged
Pages: [1]
Print
Jump to: