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
- The entering into a system depends obviously on the underlying
groupware system. So the real entering must be implemented by an
ILoginHandler.
- 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.
- 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.
- 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.
- After setting up the local model and the application, the session's
channel is initialized.
- 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.
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.