first project with pureMVC

[puremvc]

So, I think I mentioned this above but the threads and projects are getting out of control!

Philip Sexton has the code worked into a utility and demo, both ready to go into the repository. I told him since he did the work to turn it into a conforming utility and demo it, I'd set him up as Project Owner. Someone has to own it. But obviously the work is still continuing in this thread and the retry policy stuff would be good to have in there. Phil is assuming that you guys will make this work and it looks as if that's happening. So I'll be happy to make everyone who wants to contribute have write access to the repository. Some projects will need several folks working on them and this may be a pilot for us to see how well we can get folks coordinated.

Philip, can you reconcile this contribution from meekgeek ? Does it make sense with what you have?

-=Cliff>

[meekgeek]

You don't have to change anything.  It's not even perfect.  Just finished it today and I thought I would share.    I needed something quick so this is what I came up with.  I don't even take ownership.  Like I said, this code was going in a different direction and is probably not the best way to go.

[philipSe]

Thanks to meekgeek for sharing his work incorporating timeout into the previously posted startup monitor code.  I am here responding to Cliff's "can you reconcile..." above.  I am interpreting the timeout requirement as set out in the meekgeek posting.  There is no connection with the app resource's actual loading process, which, once started, runs on independently of the startup manager.

The Startup Manager Utility is currently the following 4 classes:
StartupResource, StartupMonitorProxy, IStartupProxy, StartupResourceLoadedCommand.

Taking this new work into account, I think the list of classes would become:
StartupResourceProxy, StartupMonitorProxy, IStartupProxy, StartupResourceLoadedCommand, StartupResourceTimedOutCommand; plus retain StartupResource, see below.

StartupResourceProxy
StartupResourceProxy has the advantage that the client app can name it and can retrieve it, assuming it is registered of course, and can thus have access to certain properties.  I would prefer not to require that the client's own resource proxy has to extend StartupResourceProxy, since that may impose on the client app design.  Instead, say the constructor is:

:

public function StartupResourceProxy( proxyName:String, appResourceProxy :IStartupProxy )
The cient app must instantiate its app resource proxies before the StartupResourceProxys.  The loadResources method of StartupMonitorProxy can now invoke the client loads via the IStartupProxy reference held by the StartupResourceProxy.  The StartupResourceProxy and the appResourceProxy must have different names, assigned by the client app.

In thinking about the internals of StartupResourceProxy, I think it makes sense to keep the StartupResource as a separate class: the proxy is a front for the StartupResource, the data property of the proxy is of type StartupResource, the proxy constructor creates the StartupResource. So, that takes us to 6 classes in the utility.  StartupResource would no longer have the 'proxyName' property.

Let this StartupResourceProxy have
- public methods for client use, e.g.: read/write 'requires', read/write 'timeout', read accessors for 'status', maybe also a setForRetry() to cause status change from TimedOut back to Empty
- internal methods for utility own use, as in access from StartupMonitorProxy.

StartupResource
This has a new timeout property, and a new TIMED_OUT status value, with associated access methods, per meekgeek's posting. The setStatusToLoading method starts the timer.  On timeout, a notification is sent e.g. STARTUP_RESOURCE_TIMED_OUT.  This is handled by the StartupResourceTimedOutCommand, which in turn calls the StartupMonitorProxy#resourceTimedOut method.  Questions: is there a non-zero default timeout? a timeout of zero means we ignore timeout? For now, my default would be zero.

StartupMonitorProxy
- resourceList is now a list of StartupResourceProxys
- let addResource() continue to have just one arg; let the client app set the timeout for the resource directly via the StartupResourceProxy
- resourceTimedOut(): set resource status, add to timedOutResourcesList
- allResourcesLoaded() is renamed to something like isLoadingFinished(), because some resources may have timed out and other resources may require those and so on, so we may be finished even though all resources are not loaded.

How does the client app know we're finished but not complete? Say we send a LOADING_FINISHED_INCOMPLETE note instead of a LOADING_COMPLETE note.  In the incomplete case, we could send in the note body an array of the incomplete StartupResourceProxys, to make it easy for the client to set those for retry if desired.  And if retry is desired, the client invokes monitor.loadResources() again to try the outstanding resources.  I know Cliff expects features that cause the utility itself to retry a number of times before reverting to the client, but I'm ignoring that for now.

IStartupProxy
Continues to just have the 'load' method, I don't see an example use of 'onComplete'.


Cliff/Meekgeek/others - any comments on the above?  Subject to your comments, if this is worth doing, it may be easiest for me to incorporate this into the utility at this time, since I have my hands on it.

Regards
    Philip

[puremvc]

I like the resposibilities of these actors. And retry policy management doesn't necessarily need to be there, just a sound way for the app to handle it as you described.

And definitely I'd default retry to 0.

Retry Policy, even if a separate util,  needs to handle throttling by controlling not only timeout and number of retries but also time between retries. Also, some  services want a minimum time between requests successful or not. So perhaps this is really another utility.

-=Cliff>   

[philipSe]

I just want to add a correction and an addition to my post above regarding timeout and the StartupManager utility.

1. Forget the setForRetry() idea.  Better to leave the resource status as timed out.  Then the client app simply invokes retry by a retryLoadResources method on StartupMonitorProxy.  The client doesn't have to reset individual resources.

2. We need to allow the client app to notify when a load process fails, e.g. <resourceABC>_LOAD_FAILED and have a new class in the utility StartupResourceLoadFailedCommand to handle such notifications.  Such failures are like timeouts in that they result in the LOADING_FINISHED_INCOMPLETE notification from the utility.

Regards, Philip