Bridges to framework
With ConcertChat we try to have minimal functional requirements for the underlying
communication framework.
That is, our approach is to have a lightweight server and a heavyweight client.
The client needs to compute nearly everything, but at least the channel messaging
must be done by the framework.
In this package we define the interfaces which must be
implemented to connect a ConcertChat client to the framework.
Entering the groupware system
The client-server communication uses the following concepts:
- ILoginHandler: The LoginHandler is used to enter the system. It
does the authenification and allows to enter certain sessions. Each loginHandler
has it's own clientID, so one user can be logged in multiple times.
- ISessionChannel: Being logged in, the client
can now enter a session (ISessionChannel) with a certain nickname.
- IPersistentChannel: After successfully entering a session the session
holds an IPersistentChannel, which should be used to send and receive the channel
content, and a user list containing all the present users in that channel.
We assume the following general steps to enter a chat room:
- logging in into the system:
Given the server URL, authenticate with a login handle and a password.
This might be denied, if the user is not registered or the password is wrong.
- entering a session, chat room, channel, resp.:
given a nickname and a room name, enter the room. This might be denied, if
the nickname is already in use.
If it was successfull, the returned session stores a user representation of
the current user in the entered session. That is, for each
simultaniously entered session the user might have it's own user representation.
Different framework details:
- pure frameworks (like the servlet based approach) might not have a
user authentication. So the first step is ommitted.
- some messaging frameworks are strictly asynchronously: on the client side a
login request is generated, but the answer is received by a listener. So the
login-method is not blocking.