2010-02-09 - Meeting @ ISTU - LUI + LLF capabilities and responsibilities

Conversation Parameters

Date/Time: 2010-02-09 10:00 - 13:45 CET

Action Points are marked with "AP:"

Participants

Transcript

  1. WS presents reference architecture V 0.5 and explains role of LUI components
  2. CB and PM point out capabilities and already existant functionalities of eHome framework
    1. CallBack, as in LLMCMSS.05.02.08 is already supported via SOAP-API, accepts events, with configurable action
    2. Invoking web services is already available, although for each new or changed web service, a new "SOAP Driver" has to be built or re-built, which has to be done in the development environment at ISTU
    3. There is already a control embedding the Internet Explorer web browser to that rendering of arbitrary HTML, including Flash and JavaScript is already possible.
  3. LLM shall make very conservative use or varying control types inside the LLF. As of the time being, only the following controls shall be used:
    1. Buttons with variable states (images, active/inactive, present/absent)
    2. Rectangular HTML rendering areas, but without tabs and no active components, which can directly get their content by querying an URL presented by the framework.
  4. AP: WS: to amend LLMCMSS.05 according to results of this meeting, thus delivering Issue 0.5 or 0.6
  5. ALL reach agreement of required functionality to be provided by LLF in addition to existing eHome Version (all other requirements are already met):
    1. data dependent controls (for result selection) as in LLMCMSS.05.02.09 will have to be implemented
    2. SOAP "driver" will have to be developed LLM-specific in order to perform SOAP-calls to CMS and LRF
  6. PM points out that in order to achieve the most efficiency in LUI development, ISTU should do the LUI development. LUI development will be most probably only configuration, if LLF is complete. This new work split is already reflected in LLMCMSS.07, Issue 0.6, especially LLMCMSS.07.02.02.03.
  7. AP: WS: CEIT shall be asked to provide a LLM-LUI-"Style Guide" containing layout and color schemes for all LUI screens. ISTU will review it with the experiences of the eHome deployments.
  8. Together with the style guide and the screen definitions from LLMCMSS.06.04 ISTU should be able to develop all LUI configuration.
  9. Login-plugins may be supported by an alternative approach than compared to this in LLMCMSSS.05 Issue 0.4, thus presenting less cohesion and uncertainties:
    1. An authentication token reader (for smartcard or NFC or even WiiMote) may send an Event to the LLF instance via the LLF SOAP API.
    2. This event can then be flexibly processed inside the LLF.
    3. This also opens ways for login and logout processing based on token presence or absence. However, LLM Version 1 shall make very conservative use of such mechanisms as the use cases and work flows are not yet completely worked out and may present more trouble than good at the time being.
  10. Callback-API shall carry only Events, how these are treated shall be hidden inside the LUI configuration
  11. LLF consists of only one window at a time
  12. When navigating through menus/dialogues, content of window is replaced by control set of new dialogue
  13. LLF keeps history of last 100/configurable dialogues and allows to go "back" in this history if convenient e.g. on button
  14. LLF monopolizes keyboard and mouse (pointing device), filters all events from these and allows only a few selected ones to be processed for its own purposes.
    1. Any other application window is hidden BEHIND the LLF window
    2. Any other window is deprived of keyboard and pointing device
  15. For the purpose of allowing an external program to run (e.g. for CTC-integration) the LLF will have to:
    1. start an seperate process and monitor it until it terminates
    2. release keyboard and mouse and stay behind the external program window during the execution of the external program
    3. wait for termination of the external program and re-monopolize keyboard and mouse
    4. start a timout supervision of the external process in case it refuses to terminate.
    5. In timeout case LLF has to kill the external process with potential damage to the system environment. This must not be the normal way to terminate such an external program. The circumstances shall be logged in order to prevent repetition of such cases.
  16. All LUI screens shall provide an "Emergency/Distress" Button with similar function than eHome:
    1. present a confirmation screen ("Really a problem?") with option to go back
    2. place a SIP-call to an emergency destination if confirmed (or confirmation question timed out)
  17. External programs need to provide a "Distress/Emergency" Button similar to the one on the LLM-LUI screens. This is necessary, because the external program will obstruct the LLF-based windows during its execution. Especially this applies to the CTC integration. The PTC integration is not affected as the PTC has no external user interface (during PTC training a LLF-based dialogue will be displayed featuring the distress button).