Concepts

ConcertChat applications are based on chat rooms: entering a system means also entering a chat room. Because the chat room implies that you send and receive chat messages, but we allow to send nearly everything, we call that chat room ISession.

Logging into system

  1. The entering into a system depends obviously on the underlying groupware system. So the real entering must be implemented by an ILoginHandler.
  2. The ILoginHandler realizes entering the system into a special chat room. The room is identified by a name. When the client is connected to the system, the passed ILoginObserver is notified by handing over an ISession object. This ISession is bound to one IPersistentChannel, but this channel is not yet initialized, that is, you cannot send objects or receive anything.
  3. The ISession object must be entered with a nickName. How this is done is up to the framework bridge, but when it succeeds or fails, the ISessionJoinObserver is notified.
  4. Now the client has in principal access to the session, but the session's channel is still not initialized, because now the local model needs a chance to setup, that is to register to the persistentChannel and so on. Also the application must be created and served with the local model.
  5. After setting up the local model and the application, the session's channel is initialized.
  6. Now the application is fully connected to the channel, it receives messages comming over the underlying channel, the history can be asked, messages can be send.
  7. Problem of Referencing: What we want to have is a lazy document loading. That is, if a target of a reference is not yet know, we load it when requesting it. That implies, that we know, which model is responsible for loading it. Examples: A message is linked to 1. Another message: --> All messages between the target message and the first known must be loaded. Here is the real problem: to which "subchatroom" does the message belongs? This must be encoded in the targetID. 2. A Screenshot: --> Usually all screenshot meta informations are loaded at startup, so we "know" the document (and the model loads the real image data on the fly) 3. An URL: --> The URL is encoded as reference target ID, so the document is "known". 4. A whiteboard: --> The document is known The IPersistentChannel can cache the mapping between ID and type. So before sending a message with a reference, the target's type can be inserted in the reference. When the referencePanel looks for a targetViewer, it can check, whether the reference is not yet resolved. If this is the case, the referencePanel can call a registered documentHistoryLoader for the target type to load the document.