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.

LLMCMSS.05.01 LLF platform

1. The LLF shall run on Windows (XP,7)
2. The LLF shall be tested on the following hardware platform(s):
   1. ASUS nettop as in eHome installations
   2. Desktop WinXP/Win7 PC specified for CTC software
3. The LLF shall operate on the following Operating System Environments:
   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.
2. Multi-Window: The LLF shall be aware of and being able to control multiple windows displaying user-I/O for multiple applications. These applications may be LLF-based or completely different, the only thing in common being the same local terminal (i.e. display/desktop)
3. Navigation Controls: There shall be controls to lead to another dialogue with a different set of controls. The new dialogue shall be able to be displayed:
   1. in the same window like the invoking dialogue, replacing the invoking dialogue
   2. in a new window. In this case, modality shall be avoided as it is generally too complicated to understand for a user. If the "calilng" dialogue has to wait for the called dialogue to be completed, the called dialogue shall be opened in the same window like the calling one, returning to the calling one after  completing all activity in the called dialogue
4. Multi-Window Control Action: Activity by a control in one window shall be able to affect configuration and appearance in another window. In order to limit cohesion, impact shall be able to be limited to a specific control in the target window by configuration.
5. 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.
6. 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. 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 latterrequests it due to an alarm, notification or similar. This requires amending the application, but only to a certain extent.
   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 Internet Explorer engine embeddable into any .NET application.
7. Apart from the interaction on the GUI level, other integration needs to be taken care of:
8. User credentials and authentication. The invoked application needs to run within the security allowances of the logged-in user on the LLF level.
9. Data storage. The invoked application shall be enabled to place generated data in the LLM-DB via the WS-API
10. Configuration. Like data storage, the invoked application needs to be enabled to take configuration information from the LLM-DB via the WS-API.
11. 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.

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.
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.