That's great Steve.  Glad to know you have a clean compile.  BTW, we don't have umbrellas on our drinks in the West Of Ireland.
----Philip

Steve
Ok, ok, I'm sorry I mentioned the 'relaxing' word.  Good luck with the new house.

You may already know: the multicore src of startupmananager (sm), from which the multicore swc was built, is under the multicore folder in trunk.  It is just standard with the import statements changed.

If there is a problem with this swc, I'm not asking you to resolve it - since I built it I should step forward to resolve it, and will do, and will give it priority over other things (including that r word).

Now, maybe you already believe/know that the prob is with the swc.

If we have the sm multicore swc, plus startupasordered (sao) changed for multicore, plus asyncstub (as) changed for multicore, and we get compile errors that cannot be resolved through sao or as, then it looks like sm is the problem.  Is that where we're at?  I can see that the error line that features 'undefined method retryLoadResources' would seem to indicate an sm error.  And now I realise that this method is superseded by 'tryToCompleteLoadResources()' in this latest sm, which indicates that the sao in use is not the latest version.  The latest sao is required for the latest sm.

Hope this helps.
----Philip

Steve
I don't have a ready answer for you.  The errors seem to be related to startup as ordered, isn't that right?  Where is the reference to the non-multicore IProxy coming from?  I would like to reproduce what you are doing, and then play with it.

Unfortunately. I am on holidays this week and next.  Internet access is not readily available.  And anyway, I'm supposed to be relaxing and so on....

I look forward to seeing info on any progress you make.
----Philip

Steve
Ok, now I can be more precise - tis the bin folder.

For startup manager utility, in the bin folder under trunk in the svn repository, there are 2 swcs, one for standard and one for multicore, the latter being named Utility_AS3_MultiCore_StartupManager_1_3.swc.  I haven't actually used this myself, but I would encourage its use and would appreciate feedback.

This bin folder is not part of any tagged release, as far as I know.

Cliff, what is the best way to make this available?  Is there read access to the repository?

Hopefully, this swc will resolve your problem.
Regards
----Philip

Steve
Just want to make sure you know there is a separate swc for startup manager utility with multicore.  It is under a multicore folder, under trunk in the svn repository.  This is a hurried reply, and hence unable to be more precise.
Good luck.
----Philip

Addition to above post, re getting reference to StartupResourceProxy (srp) object...
The client app creates the srp object, so it could choose to keep a reference to it on the corresponding app proxy, which is retrievable by its proxy name.
----Philip

Have you considered whether the StartupManager utility could be useful for this?

As regards your solution options, I prefer A.
----Philip

The practice of passing the app resource proxy name in the body of notifications sent from the startup manager began in the original custom versions before the release of the utility and was retained in the first release (v1.0).  At that time, the StartupResourceProxy was a much simpler class with state consisting just of the status property and that app proxy name.  So, it was thought that all the client app would need would be its proxy name, rather than needing indirection to get to it.

However, I can see a strong argument that it would be better to pass the reference to the StartupResourceProxy object in the notification, as you suggest, and then have related information available indirectly from that.  There is the question of being kind to existing implementations and minimising the migration chore.

As things stand, ways that you can get a reference to the StartupResourceProxy, include
1. if you know its name, facade.retrieveProxy()
2. something like the following should work: monitor.getResourceList().resourceList which gives an array of StartUpResourceProxy objects, and then search that for a match on the app proxy name using the appResourceProxyName() method on each object.

As regards the failed count, I think you already know that it should be available as follows

:

(r.retryPolicy as RetryPolicy).getFailedCount()where r refers to the StartupResourceProxy object.  However, as you say, it is not exposed by the IRetryPolicy interface.  It would be better if there was a getter for failedCount as part of that interface.

These points are worth considering in future contributions to the development of the utility.
---- Philip

I've just seen your post.  I wil look into it and get back to you as soon as I can.
----Philip

The loaded notification is essential when there are dependencies, otherwise dependent resources will not get loaded, since the monitor will not invoke the dependent loads until it knows the independent one has loaded.

When there are no dependencies, the monitor will invoke all the loads but it won't know they've completed if loaded notifications are not sent, so the monitor will not send its completed notification.

To be precise, it is the application proxies that implement IStartupProxy, not the StartupResourceProxies, but I'm sure you know that.

I hope your problem is solved by dealing with the loaded notifications.

Now, I have glanced at your code, note 'glanced' so forgive if I misread.  My comments are as follows
- ensure that you have looked at the api docs for the startup manager, so that you understand what it expects from client applications
- each instance of application resource proxy (your ResourceProxy class) must have a unique proxy name; this is critical in the context of loaded notifications so that the manager can distinguish which resource has been loaded; I think your constant NAME variable is being used 
- setting defaultRetryPolicy on the monitor in the LoadAssetsCommand, having already done it in the StartupCommand seems unnecessary and may even be wrong.

Let me know your progress.  Good luck.
----Philip

First, let me know that you are stating the dependencies and adding resources in the expected way.  For example, here are some lines from the source of the StartupAsOrdered demo.

:

        var rInv :StartupResourceProxy = new StartupResourceProxy( InvoiceProxy.SRNAME, invPx );
        facade.registerProxy( rInv );
        rInv.requires = [ rDAcc, rSO ];
        monitor.addResource( rInv );
        monitor.closeResourceList();

These lines occur within commented code in the LoadResourcesCommand class.  They are meant to illustrate the api when the resource list is open.  Notice that the requires method sets the dependencies on rInv before rInv is added to the monitor.  This is because addResource() will cause immediate activity by the monitor and the dependencies must be known beforehand.

Anyway, maybe you have the above point covered.  The next point to cover is that after the load of your A resource, you must send the loaded notification so that the monitor knows to proceed with the other loads.  And of course, your B/C/D proxies must implement IStartupProxy by having a load() method.

Let me know your status regarding the above points.
----Philip
BTW. This discussion should perhaps be under the StartupManager topic i.e. Forums /Port to as3 /Standard version

Yes Steve, I'm sure one could interpret the role of these entities in that way.  The key point was that I didn't choose to put any further effort into the demo, to have it illustrate any more of the startup manager features.

The only reference to the open-ended resource list feature is the block of code commented in the LoadResourcesCommand class.  I included this just as an illustration of how to use this feature and so that a developer could easily activate it instead of the standard code and thus rebuild the demo and see the altered execution.

Of course the option is there for somebody to enhance the demo or make a different demo.
----Philip

For what it's worth, here are my thoughts regarding the file sizes requirement, if trying to extend the startup manager
- the sendProgressNotification() method, should be protected access rather than private, to enable override [ should have been protected access anyway!!!  ]
- StartupResourceProxy to have new properties such as 'number of bytes' and 'load rate'
- ResourceList (IResourceList) to have getters for such as 'expected total number of bytes to be loaded', 'number of bytes loaded', 'average load rate', 'load start time', 'expected load completion time'
- then sendProgressNotification() might be able to send the required progress information
- time-based sending of the progress notification, as well as on completion of each resource load.

Better still, encapsulate all the progress percentage calculation within ResourceList, with a single getter 'percentage complete' that sendProgressNotification() can use.
----Philip

The startup manager (sm) , as use of it has evolved, can be used at any time, not just at startup, and is not necessarily particular to the model layer.  The internals have nothing specific to the model layer, it seems to me.

The choice of resource type arises within the client app, with the app's proxy, which must implement IStartupProxy and that is simply a load method.  This is the area which could be analysed so that common requirements could be bundled into a separate utility, which would in turn use the sm utility, or could be met by an enhanced sm utility if that made sense.  If this is the area that needs attention, it seems a shame to discount use of the sm as a body of core fucntionality.

You would have the ability to start and stop a load, load multipy files. Maybe even have it be aware of what type of file it's loading.  Factory pattern comes to mind... something with keys so you can refrence an image by name, if it finds it return Bitmap, if not load and return.

Taking the above quoted points, and interpreting them as logically inside or outside the existing sm
- start and stop a load: outside, local to the client app proxy; is it critical that the overall monitor be able to do this?  what is the example case?
- multiple files: inside, existing sm functionality
- be aware of file type: outside, local to the app proxy; again does the overall monitor need this awareness?
- factory pattern...if it finds...if not...: outside, local to the app proxy, the load method can have this lookup logic and can send a loaded notification if the resource is already loaded.

I think we need greater detail on the example case, so that we can see where the sm is deficient - is it in the core functionality or is it in the peripheral functionality?

----Philip

Your button component can dispatch an event that can bubble up through the component hierarchy.  In the menu mediator, you can add an event listener to your menu component, the event listener being in the mediator as usual.  The menu component will see the event, provided the button component is below it in the hierarchy.  Does this help?  Have I misunderstood?
----Philip