Scenario 1: The SessionServer connects the crashViewers among themselves and controls the comunication with the aid of a token allowing interaction control. Events or camera parameters are exchanged directly between the instances of crashViewer.
Working cooperatively it is substantial to let two or more users being
spacially seperated have a uniform view on the model. Simultaneously discussion
for example via telephone is possible without making any of the involved persons leave his work place.
Here the following sceneries can be distinguished:
For both scenarios CORBA based methods of resolution have been implemented in crashViewer. The first scenario requires the application crashViewer as well as the data to be visualized are available on the computers of every participant. But in the second one on the client side (viewer) only a JAVA application or a HTML browser is needed.
Scenario 1: The SessionServer connects the crashViewers among themselves and controls the comunication with the aid of a token allowing interaction control. Events or camera parameters are exchanged directly between the instances of crashViewer.
In scenario 1 the initiating user first starts a controlling application called SessionServer. That makes available his own CORBA reference and now allows a crashViewer to open a new session or to register for an existing session. The task of the SessionServer is to connect the participating crashViewers and spread the token allowing interaction with the displayed model. crashViewer does not only save the reference to the SessionServer but also the references to every other crashViewer participating in the session.
At every time only one crashViewer can take the control. For example if the the eye point is changed the controlling crashViewer submits the camera parameters directly to all the other participants. The token enabling the control is managed and assigned by the SessionServer. It can be exchanged between the participating crashViewer instances, so the change of the interaction control is possible.
The setting of marking arrows at the model makes communication easier. If the model data is not available for every participant the COSMO3D scenegraph can be requested by the controlling crashViewer and be submitted.
Scenario 2: crashViewer provides the drawed picture data at a port that can be read out via a socket connection. To be able to ensure a higher transmission speed compression techniques are used for the transmission of the pictures.
Scenario 2 allows an active crashViewer user to make the displayed model available in form of encoded picture information at a socket. With the aid of a JAVA application the passive participants of the session can read and decode the compressed picture data of the socket and display it in a graphic capable window. Together with a JAVA applet a HTML page has been created, for example to load it with netscape, that displays the picture drawed in crashViewer.
Because of the big amount of data, depending on the size of the pictured area and the chosen compression technique, and the bandwith of the connection the picture rate is lower on the side of the reveiver. Still this technique allows to a certain degree cooperation with very low requirements on the client side.
Here the the picture momentarily displayed in crashViewer is compressed, transfered via socket connection to the JAVA applet running in a web browser, is decompressed there and finally displayed.