One of the goals of the node.js external adapter development project is the ability to create Vca based servers and services using node.js. Among other things, such services need to support and conform to the FAAS service lifetime management conventions and APIs intrinsic to Vca. For example, one very common use case requires the ability to dynamically start an instance of a node.js based service on demand, keep that service alive for the duration of its Vca based consumers, and eventually and quietly shutdown that service when no longer needed. In short, server-less FAAS, in addition to the other lifetime management policies provided by Vca.
Implementing this requires an effective way to detect run state changes in the Vca::Application subclass providing the service. Surprisingly, while there are a number of ways to do this in the current implementation of Vca, especially for external monitors, there was no direct way to do this for sub-classes of Vca::VApplication. Simple to address by providing an overridable virtual member function at Vca::Application, that (plus a pair of benign tag-alongs) is the purpose of this PR.
One of the goals of the node.js external adapter development project is the ability to create Vca based servers and services using node.js. Among other things, such services need to support and conform to the FAAS service lifetime management conventions and APIs intrinsic to Vca. For example, one very common use case requires the ability to dynamically start an instance of a node.js based service on demand, keep that service alive for the duration of its Vca based consumers, and eventually and quietly shutdown that service when no longer needed. In short, server-less FAAS, in addition to the other lifetime management policies provided by Vca.
Implementing this requires an effective way to detect run state changes in the Vca::Application subclass providing the service. Surprisingly, while there are a number of ways to do this in the current implementation of Vca, especially for external monitors, there was no direct way to do this for sub-classes of Vca::VApplication. Simple to address by providing an overridable virtual member function at Vca::Application, that (plus a pair of benign tag-alongs) is the purpose of this PR.