Sessions and application settings

This document covers the details of how client applications should be able to store configuration settings and temporary information in BASE.

Contents
  1. Sessions
  2. Settings
See also

Last updated: $Date: 2009-04-06 14:52:39 +0200 (må, 06 apr 2009) $

1. Sessions

  1. BASE should be able to handle multiple simultaneous logins, sessions, to a single user account. One session must not interfere with another one.
  2. [WEB CLIENT] The web client should be able to handle multiple logins to the same account or to different accounts from the same browser on a single workstation.

2. Client application settings

  1. A client application should be able to store configuration settings in BASE at three levels:
  2. BASE may define settings that can be of general interest for several client applications. The meaning and use of such settings should be specified in some documentation. A client application may choose to ignore those settings.
    [NOTE] We have decided to not specify any settings of this type at the moment. However we reserve all names starting with global. for future use for such settings.
  3. All settings are read from the database at login time, and are kept in memory until the session is finished (ie. the user logs out). Settings that have changed are then saved to the database.
  4. A setting is a string value identified by a name, which is also a string. The name must be unique for each type of setting.
    [QUESTION] Or, should we use numeric keys and define constants in the core and applications?
    [ANSWER] No, it would only be cumbersome to handle.
  5. [QUESTION] Do we need more powerful structures for storing settings?
    [ANSWER] No, not at the moment.