LLMCMSS.05 - LLM Local User Interface Framework (LLF)  Specification

This part of the LLM CMS Specification specifies the framework components on which all local user interface components - LUI - shall be built upon.

As the LLF is considered as an external component to the CMS subsystem, it can be considered as if had an "ENVREQ:" in front of it

LLMCMSS.05.00 Document Control

LLMCMSS.05.01 LLF platform

1. The LLF shall operate on a local terminal platform
2. The local terminal shall have following attributes:
   1. Hardware platform(s):
      1. ASUS nettop as in eHome installations
      2. Desktop WinXP/Win7 PC specified for CTC software
   2. Operating System Environments: Windows variants:
      1. Win XP 32 bit
      2. Win 7 32 bit

LLMCMSS.05.02 LLF Functionality

1. Basic Operation Mode: The LLF shall present the user a dialogue with a collection of controls, displayed in a window. Controls may have varying graphical design and functionality.
   As of LLM V 1, only the following controls shall be used:
   
   1. a "button": arbitrary 2D-shape with action at touch, with properties like active/inactive, (in)visible and configurable changing pictures, all controllable by actions performed in the LLF instance
   2. an "HTML-rectagle": a rectangualr area where HTML-code is rendered into. Apart from directly passing HTML document, an HTTP-URL shall be able to be passed and the control then itself GET-ting the HTML document.
2. Navigation: There shall be activities, triggered by events or control interaction, to lead to another dialogue with a different set of controls. The new dialogue shall be able to be displayed in the same window like the invoking dialogue, replacing the invoking dialogue
3. A control shall be able to perform arbitrary functionality, especially performing actions on instances of Web-Service-Interfaces. Possibilities may be limited by the fact that a control is executed in the context of a specific platform. The activity carried out may be intended to affect a software component running on a different physical or logical platform or a seperated security realm. In all such cases, the LLM architecture calls for interaction via a web service interface.
4. There shall be a set of controls capable of "wrapping" already existing software applications running on the same platform. Depending of the ability of such applications, there may be different types of interactions and therefore different control implementations to interact with such an application:
   1. "Uncooperative Application": Such an application cannot be controlled in any way by the LLF control except for invoking it with an operating system call. The control shall at least monitor the existance of the invoked process and be able to modally block the LLF window during execution of the application or allow parallel execution.
      1. LLF shall release its monopolizing grip on display Z-axis (LLF normally always on top) and input as well as pointing devices
      2. However, a set of safety and stability measures must be implemented:
         1. A timeout for modal or quasi-modal application windows to "escape" in case of a locked up application. Such application windows would prevent other activities while executing. If such an application does not terminate properly, all LUI would be locked up. Such a case needs to be avoided under all circumstances.
         2. process supervision for the application to detect creashed application processes
         3. measures to communicate the application status back to LLF to update the state of controls and other state-induced data
   2. "Cooperative Application": Such an application at least supports bringing another LLF window to the front of the display when the latter requests it due to an alarm, notification or similar. This requires amending the application, but only to a certain extent:
      1. The application needs to provide UI controls to send events to the LLM application system, e.g. for an "emergency/distress" button
      2. LLF shall be able to push itself back to fron in certain cases, thus obstructing the applications window and again monopolizing the input devices.
   3. "Integrated application": such an application can be run inside a client window created by the LLF instance and therefore fully blended with the LLF look-and-feel. A model for such a mechanism would be the ILC LUI as its based on the predecessor of the LLF and therefore can be deployed into an LLF instance.
5. Apart from the interaction on the GUI level, other integration needs to be taken care of:
   1. User credentials and authentication. The invoked application needs to run within the security allowances of the logged-in user on the LLF level. If such a "token switch" is not possible, the LLF instance shall at least run under a accoiunt without elevated privileges and carry real user authentication information and credentials as parameters on the application level.
   2. Data storage. The invoked application shall be enabled to place generated data in the LLM-DB via the WS-API
   3. Configuration. Like data storage, the invoked application needs to be enabled to take configuration information from the LLM-DB via the WS-API.
   4. The Data storage and Configuration Issues can be resolved in the worst case by "brute force wrappers": Such a wrapper would wrap around the application to be invoked and, at the start, retrieve the configuration and input data from the LLM-DB using session information and credentials. It would generate the input data in a format suitable for the invoked application (e.g. config files) and then invoke tha application. After completion of the application, the wrapper would collect all output (e.g. from statistics files etc.) and stuff it into the LLM-DB. This looks like a very crude process but could be the last resort with very non-cooperative application the LLM-project has no control over.
6. Call-Back Functionality: The LLF shall allow for an external application to control certain behaviour of the local terminal display:
   1. LLF shall offer a SOAP-API for each LLF instance on a local terminal
   2. API shall allow to inject events into the LLF instance, actions for handling the event shall be to the sole discretion of the LLF configuration
7. Data Dependent-Controls: There shall be controls whose appearance shall be dependent on data values, i.e. on the result of a library call:
   1. Any arbitrary control or control group present or absent based on library call result
   2. button active or inactive ("greyed") dependent on call result
   3. number of controls in a control set dependent on cardinality of a function return set
   4. Button image or text dependent on the return value of a library call, e.g. image file name returned by library call, e.g. as a property from LLM-DB
8. There shall be a well-separated way to employ different input devices, such as security tokens, smartcards and input devices not mapping to mouse and keyboard abstractions. Such devices shall have their own integrations and shall propagate application-specific events to the LLF-instances, much like in the callback functionality above. Examples are:
   1. login via smart card: card reader in scanned by integration application. Inserting, removing  or swiping a card may result in generating a "login_request(credentials)" or "logout_request()" event to the LLF which may handle it or even ignore it in states noit appropriate of loggin in or out.
   2. dialogue responses via WiiMote-gestures: the integration software may decode the gestures (like "yes", "no", "up", "down" or even "emergency") and forward them as events with the respective meaning to the LLF-instance. If there is a dialogue with responses required like yes and no, the yes and no events will be accepted, otherwise ignored.

LLMLCMSS.05.03 - LLF Implementation and Modularity

1. LLF Implementation Code and Application Implementation Code shall be separately developed and maintainable. A system of dynamically loadable libraries (DLLs) along with a data-driven configuration data set shall be employed to achieve configuration flexibility, expandability and separation.
2. A sensible application of an MVC-(Model/View/Controller)-Pattern shall be followed. However, it is a definitive NON-GOAL of LLF to greatly re-design the basis software framework taken over from eHome, but all measures available shall be taken to carefully separate appearance from content from function flow.
3. Types of controls and other visual elements shall be able to be packaged separately and deployed independently. Multiple packages shall be able to be deployed into the same LLF instance and be distinguishable by a prefix/namespace-paradigm.
4. LLF shall allow for separated 3rd-party code libraries to be used by control implementations. One example for such a library would be a web-service client-library to access the LLM-DB or to access other LLM functional components
5. The variant of implementing LLF as a web-browser based frontend shall be kept in mind and re-evaluated at every new release of LLF. Existing CTC implementations already have web-frontends. Component-based web-application frameworks like Apache Wicket provide a large number of GUI controls providing native-like look-and feel by freeing LLF design from tasks and sotware components that are already existing in the market. Moreover, implementations like Apache Wicket are Open Source and free software. 

LLMCMSS.05.04 - LLF Configuration Management

1. There shall be multiple LLF configurations per HW/OS-platform instance. These may be named "configuration" or "instance". One instance shall be configured by one set of configuration data and shall use one specific version of software components. Instances shall be able to be functionally and security-wise isolated from each other. However, only one LLF instance may be active at the same time as LLF monopolizes the Z-priority and input devices. Multi-display configurations like citrix or terminal server or virtualization shall be definitely NON-GOAL for an LLM local terminal.