SRAppFrame

is "only" a frame or environment for the loadable applications and for so slightly invisible. It offers base functionality like database access, configuration by XML-files, desktop-environment for loadable applications, interface for loadable services, etc.

So the jar-file SRAppFrame is more like a rack than an image - a rack gets its value from the things you put in - so SRAppFrame gets its value by the extensions loaded at runtime.

SRAppFrame is the application executed by the enduser, but the real application is the extension from a subdirectory loaded at runtime.

One of the visible parts of the application frame is the "About"-dialog, which tells some information about the application. This dialog, as well as most of its content is created by the application frame. Each loadable application may tell about itself in a given area and all those areas are displayed in a scrollable box.

Another dialog from the application frame is the settings dialog. There exists settings common to all applications (like database connection parameters) and those unique to each loadable application. So each loadable application may create a dialog-page, which the application frame takes to build a multipage settings dialog. The common pages are the first (desktop) and the last (services).

Systemservices are setup in the database at installation time and are not editable. But the configured services can be customized. The customizable settings of services are the sleep time, the time, each service likes to sleep when it is bored. Than - naturally - the log configuration and the services commandline parameters. Not every service takes commandline parameters, so the textbox may keep empty. A service, that needs parameters is the EPG-importer.

New: for each service, two scripts may be defined. A pre-start-script and a post-stop-script. Both scripts may be the same script. The pre-start-script is intended to be used to wake another machine by WOL and mount an exported drive. Therefore a trigger-file may be defined. That triggerfile may be a file from the exported drive, so the successful mount can be validated. If a triggerfile is defined, the service will be started only when the triggerfile exists.

Beside the filenames, two sleeptimes can be defined: the sleeptime before start and the sleeptime after stop. The sleeptime before start is intended to match the boot time of that machine + the time needed to mount the exported drive. The sleeptime after stop is intended to ensure that the service has no more locks on the exported drive, so that it can be unmounted.

See also Services / Service-Manager