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]
Print
Author Topic: New to Multicore - big Flash app planning  (Read 15469 times)
jowie
Jr. Member
**
Posts: 19


View Profile Email
« on: May 08, 2008, 10:07:30 »

Hi Cliff and the gang,

We're about to embark on a fairly large project in Flash which needs to be written in a fairly modular fashion. I am sure MultiCore lends itself well to the project but I am unsure about how to go about implementing it, so I was wondering if you could help.

The basic layout is a shell SWF which deals with loading and playback of sub-SWFs. Each of these sub SWFs is going to be a game or similar, and will probably have its own PureMVC core. The main shell SWF will need its own core too.

What I need is to create an API of sorts for communicating (hopefully sending Notifications) between the cores. Is this possible? So for example, my shell SWF loads in game 1 and sends a notification to it to play. When the game has been completed successfully I would like the game core to send a notification to say it has finished which is then picked up by the shell core so it may carry on.

Is MultiCore right for this project? Does anyone have any clues as to how to lay it out so the cores may communicate between each other in this fashion?  ???

Thanks!  ;D

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



View Profile WWW Email
« Reply #1 on: May 08, 2008, 01:03:11 »

You don't really want to send notifications between modules. This means that they must share a definition of the notification name, and you must come up with a system for keeping those names unique. This would become unmanageable if you later have third parties writing modules, and you can't control the notification namespace. Interface calls are a better way to go. This defines in a single 'contract' what the communication between modules and the shell will be. I would suggest you investigate the Modularity demo to see how it deals with the interface between the shell and the module.

You can also have the modules dispatch events and have a mediator in the main app listen for the events from its module like any other view component.

But don't share access to facades and notifications between modules. Bad juju.

-=Cliff>
Logged
jowie
Jr. Member
**
Posts: 19


View Profile Email
« Reply #2 on: May 09, 2008, 03:20:47 »

Hi Cliff!

I apologise in advance for my lack of Flex knowledge... I've been poking around with the modularity demo, trying to work out what goes where.

I notice you have set up interfaces for both Widget and WidgetShell... However I am wondering if this level of complexity is more than we need for this particular project. I believe we can do all we need to do through means of dispatching events... I was wondering if you agree.

The loader engine of the shell will be responsible for loading in the "widget" SWFs and storing them in a cache for later playout. When it comes time for the SWF to be shown on-screen. Once the SWF is displayed on-screen (through the Loader Class), all I should need to do is send it a message via a function call to start playing. I guess therefore I could make use of an IWidget interface for this to be completely safe.

Unlike Modularity, the Shell should have full control over the SWF so I'd probably shy away from passing the shell instance into the widget. The widget only needs to send certain messages when things happen, such as when it has completed doing whatever it set out to do. Since there will only be one widget active at any one time, I could communicate this information to the shell via a custom event... Do you reckon that is okay?

If I ever want to add extra complexity, such as requesting the shell to do certain things (like automatically show the help screen), I could add this in as and when needed...

Can you see any problems in doing it this way?

Thanks!

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



View Profile WWW Email
« Reply #3 on: May 10, 2008, 05:47:36 »

... the Shell should have full control over the SWF...

Its fine to have the module talk to the app via events. But the app should talk to the module via a interface.

This allows you to vary the class, to have many modules that you can count upon to have specific methods. it will also help you to unit test the app and modules by being able to have mock objects stand in for the real thing.

-=Cliff>
Logged
jowie
Jr. Member
**
Posts: 19


View Profile Email
« Reply #4 on: May 12, 2008, 08:22:03 »

Okay, so it's

APP  ----Interface---->  MODULE
       <----Events------

That right?

Thanks!

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



View Profile WWW Email
« Reply #5 on: May 13, 2008, 06:12:56 »

That's it exactly.

However another issue is how can we make modules communicate with each other without having a reference to each other?

My current thinking on this problem is to create a Named Pipes implementation, whereby after the app has loaded several modules and wants them to communicate with each other without having to be mediated, we'd configure a named pipe and give both of them access to it. The pipe could also control the type of traffic that flows between the modules, ensuring only a certain class could be passed in. It could be bi-directional or uni-directional.

Then it'd be:


App    ----Interface---->  Modules
          <----Events------
                           +
Module 1 ---> Named Pipe ----> Module 2
Module 1 <--- Named Pipe <---- Module 2

Also, it might not be a Named Pipe at all but an Anonymous Pipe more like the traditional unix pipe, created on demand by the app, and the only two actors that emerge knowing about it are the modules the app connects to at either end.

-=Cliff>
« Last Edit: May 13, 2008, 06:15:52 by puremvc » Logged
jowie
Jr. Member
**
Posts: 19


View Profile Email
« Reply #6 on: May 14, 2008, 02:09:02 »

Interesting!

Is this something likely to be added to MultiCore at some point in the future? How would you implement such a pipe?

Luckily for me, I don't think I will need to have modules communicating with each other. It will probably be beneficial to me if all traffic goes through the main shell application anyway.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #7 on: May 14, 2008, 04:32:55 »

Yes, I believe this will become a utility for the MultiCore version of the framework.

A facility to communicate between modules without having to do it through the common Shell or by giving them direct references to each other will be needed in a MultiCore application with many modules that need to cooperate. Otherwise, the control apparatus becomes to cumbersome handling all the interactions between the modules when they should be collaborating amongst themselves.

In other discussions on MultiCore, I've pointed out that sending arbitrary Notifications between Modules is not the right solution, because it brings about the problem of agreeing on the Notification name without knowing each other's internals. If you defined the name inside one module, you could not be sure that the same notification name was defined in the other module, or possibly defined for another purpose. And they're not strongly typed. That's ok for the role notifications play within a single application where you control the entire notification namespace. But it makes it difficult for different vendors to write cooperating modules.

So with the idea of pipes, as with the Modularity demo it'll still be communication by contract, but instead of all modules talking to the Shell to route things, they'll be given a pipe to talk to each other through. They don't get a reference to each other (though a Shell could facilitate that if it's necessary for them to be that intimate).

I was recently looking at Microsoft’s research operating system called Singularity. This is an operating system that seeks to be totally modular and as such they run into the same problem we have communicating between modules.  They just call them Software Isolated Processes (SIPs) instead of Flex Modules. See (http://research.microsoft.com/os/Singularity/).

All communication between SIPs in Singularity flows through contract-based channels. A channel is a bi-directional message conduit with exactly two endpoints. A channel provides a lossless, in-order message queue. Semantically, each endpoint has a receive queue. Sending on an endpoint enqueues a message on the other endpoint’s receive queue.

Essentially we'd pass messages back and forth between the modules through pipes. But the classes of messages that can be passed, in both directions, could be controlled by the pipe configuration.   

And of course another nice thing about a pipe, is that you can make a pipeline. You could insert a logging or debugging 'Tee' to siphon some of the info off to other places. Or a caching filter or an authorization filter. As any unix command line aficionado understands, the possibilities are endless.

-=Cliff>
Logged
jowie
Jr. Member
**
Posts: 19


View Profile Email
« Reply #8 on: May 15, 2008, 02:29:53 »

Excellent... Sounds interesting, I look forward to it!

I was actually wondering also, is it potentially plausible in the near future for Single Core and Multicore to be merged into one single system? It would be good to know that developing a PureMVC application could then be turned into a multicore one without any messing about with the original code... Have there been any thoughts on doing so?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #9 on: May 15, 2008, 04:57:56 »

There have been thoughts, but that's about it so far.

If you don't need modular support it is perhaps overkill,
And for the other ports we have to see how much sense it makes.

-=Cliff>
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #10 on: May 25, 2008, 11:33:41 »

I mentioned having thoughts about this, and I'd like to elaborate a little on that today. I don't want you to get the impression that the future of how the Standard and MultiCore versions merge or diverge isn't on my mind :)

A key difference (pun sorta intended) with MultiCore is that requires you to use a 'multiton key' when you call getInstance(). This is because the a unique set of the Facade, Model, View and Controller instances will be managed for that key, and you can have as many of these 'Cores' as you like. This helps us leverage loaded swfs or Flex Modules to allow completely isolated PureMVC apps to be running side by side.

But if you just want a simple app, I've thought perhaps this Multiton concept is a bit heavy. And particularly in languages and platforms that don't support modular programming at all, it really would be overkill.

Sure it's not much of a requirement to pass in a string for your application name. But dropping the Standard version and forcing a migration of existing apps after the 2.0 migration is not really kind. The Standard version remains the simplest implementation of the concept and the most easily ported. And it's the reference for all the other ports at the moment as well and minor enhancements and bug fixes have to be able to be followed on those lines without having to switch to a MultiCore implementation.

So as is now outlined on the PureMVC.org About page, there are 2 versions, and they'll both continue to be maintained. MultiCore may be allowed to diverge based upon its unique needs. The question for the AS3 developer becomes what is the recommended version? Up until now, this has been the Standard version, because the unit tests weren't even ported yet. I've done that but am adding a few MultiCore specific tests now.

Porting the unit tests over, I discovered that unit testing is much easier because you can get a fresh 'Core' for each test by simply using a unique string, so you don't have to worry about setup / teardown approaches and order of tests to keep from mucking up the notification namespace and observer lists in successive tests. Once that is done, and MultiCore moves to Production status, I believe the benefits it lends to unit testing will be enough to recommend it over the Standard version for new projects.

Migrating from the latest release of the Standard version to the latest MultiCore release is currently a matter of:

  0. Replacing the swc or source code for PureMVC.
  1. Changing imports statements from 'org.puremvc.as3' to 'org.puremvc.as3.multicore'
  2. Moving any facade access out of Proxy and Mediator constructors and into initializeNotifier or (preferred) onRegister.**
  3. Using a unique string for a key when calling 'facade.getInstance()'. (i.e. Give your app a NAME, similar to Mediators or Proxies)

** Deferring facade access in Proxies and Mediators until onRegister() is a recognized best practice since the introduction of onRegister. This allows us to be sure the actor is ready to participate in any coversation it starts by whatever method of action (i.e. notification, registration, retrieval, etc.) In MultiCore, the earliest the facade property is available to any Notifier subclass is initializeNotifier, not during the construction phase.

-=Cliff>
Logged
f_tamy9
Newbie
*
Posts: 6


View Profile Email
« Reply #11 on: August 21, 2008, 01:23:41 »

Thank you for clarifying usage of the Standard version to the latest MultiCoreknow. ;)
Logged
Pages: [1]
Print