| Name |
Action Type |
Description | |
| Runtime.install(service) | Method | framework will install if not installed | |
| Runtime.publishStatus | Event |
installationStart & installationStop - "general" Status msgs |
|
| Service.getMetaData | Method | getting "meta" information - dependencies, exclusions, peers | |
| Runtime.create(name, type) | Method | construct a new service - do not start inbox or outbox - do not create peers yet | |
| Runtime.register(service) | Method | puts service in Runtime's registry | |
| Runtime.registered | Event | publish to any subscribers the newly registered service, can use onRegistered(name) | |
| Service.startService() | Method | starts inbox, outbox - and can call startPeer for all peers | |
| Service.isReady() | Method | ||
| Service.isRunning() | Method | is true at this point | |
| Service.publishShutdown | Event | notifies subscribed services of impending shutdown, can use onShutdown() | |
| Service.preShutdown() | Method | called on each service from Runtime before stopService & releaseService are called | |
| Service.stopService() | Method |
stops the inbox and outbox threads of the service if overriden super.stopService should be called any additional threads created by the service need to be shutdown |
|
| Service.releaseService() | Method | calls stopService(), detach(), releasePeers(), unregister() | |
| Service.detach() | Method | all attached services are detached - possibly should be "before"stop service because with inbox & outbox stopped this service is unreachable, and detach might require action | |
| Service.releasePeers() | Method | recursively release all peers a service might have - recently working - Yay! | |
| Service.purgeTasks() | Method | Purges all timers for the service added with addTask | |
| Runtime.unregister(name) | Method | Final action to remove service from Runtime registry | |
| Runtime.released | Event | publishes released service to any subscribers, can use onReleased | |
| Runtime.uninstall | Method | doesn't exist yet - TODO |
Rough draft of "what exists"
Currently these are method calls, and not "events" ..
register & release are the only official "events" in mrl
OpenCV Filter Life Cycle
myrobotlab
I think we need to
I think we need to differentiate what the framework does vs which method is called on the service/which methods a service should override to do custom things at that stage.
e.g. I want to call a custom cleanup method durning stopService(). Do I now need to take care of my inbox and outbox myself as well?
Lifecycle management
This is really a subset of the methods on services. Lifecycle really is having consistent programatic hooks around when certain framework related things happen to services.
https://docs.oracle.com/cd/E19501-01/819-3659/beamc/index.html
Java defines a specific lifecycle for web servers, and if we consider our services to be very similar in nature.. then the following "official" java lifecycles would be as follows:
INIT_EVENT
STARTUP_EVENT
READY_EVENT
SHUTDOWN_EVENT
TERMINATION_EVENT..
This is just one model ... we might find there are other "events" in a service that we want to hook. Off the top of my head I can think of the following
We might want pre/post hooks on each of those events... we might also want to introduce an error event of some sort.