Capture Replay mechanisms in Habanero 2

Capture Replay Mechanisms in Habanero 2.0
Report - 01/30/98 - Annie Chabert

This paper addresses the status of the Capture Replay mechanisms in Habanero 2.0 and its extensions. The first section details the differences between the Capture Replay mechanisms implemented in Habanero 1.0 and the one implemented in 2.0. This section describes the differences in the User Interface and in the implementation of the two versions. Next section reports a new feature that Chris Seguin implemented at the end of the summer 1997: the Distributed Replay facility. In the third section, I try to summarize all the future extensions we ever thought about… And finally, I discuss the Session Monitor facility

Differences in the Capture Replay mechanisms between Habanero 1.0 and Habanero 2.0

GUI differences

Actually, the only difference in the GUI between the 2 versions is the launching of the Replay process. For any other GUI functionality, refer to the "User Guide for Capture and Replay mechanisms in Habanero 1.0" paper (http://it.ncsa.uiuc.edu/~chabert/Doc/CR_Guide.doc).

In Habanero 2.0, replaying a session is not anymore a stand-alone application. It is now fully integrated in the Habanero Environment via the Replay menu from the menu bar. This menu offers several options: Replay an archived session in a single-mode using or not the Replay Editor, and Replay an archived session in an collaborative or distributed mode without using the Replay Editor. This latest option does not integrate the Replay Editor because of lack of time to habanero-ize the Replay Editor.

Implementation differences

The two versions differ in the following details:

The Replay Editor package is now under the ristra.ncsa hierarchy.

The Editor uses only the 1.1 event model, no more handleEvent(), and deliverEvent().

The TimeScroller class has been removed as it is essentially a Time Slider.

Observable and Observer mechanisms are used in synchronizing time information (session start, session length, current time, display start time for the fine scale time slider, display length) for visual presentation of the time sliders on the tool canvas.

The ScrollPane class is used to store the tools (icons, and event canvas).

A ToolsPanel class has been created to contain all tools(icon, canvas). This was needed because the ScrollPane class can contain at most one component.

Bin's mail extract dated from August 5 1997 :

"In the current version, a new class TimeCaster (extends Observable) is used to notify interested parties any changes of the time information (session start, session length, current time, display start, display

length). Now it is mostly an simple class without any data members except the inherited. I would probably move the time information (m_StartTime, m_Length, m_CurrentTime, m_DisplayStart, m_DisplayLength)

from ToolsContainer class to TimeCaster and maybe also rename TimeCaster to ReplayTimeInfo. This makes easier to keep the time information consistent (such as, when the current time changed, display start and display length may need to be adjusted). It is the most different part from version 1.0.2."

The following is Chris' documentation on the implementation of its side of the Capture Replay facilities in Habanero 2.0 (dated from August 13 1997).

There is a method to monitor streams that is built into the current system. Since it was originally created to

generalize what I had done for recording a session, and the motivation behind it was to allow for online

analysis of streams, I'll post the answer to all of isaac.

Below, I'll describe how to determine when streams were opened and closed during a session. If you want

to determine when streams were opened and closed after a session is recorded, then you need to build

sometime of postprocessor. The processor which actually replays a session on a local machine is called

ncsa.habanero.replay.LocalBatchReplay. Another processor, called ncsa.habanero.replay.Previewer, is an

example of how you could browse the events without re-executing them.

Let me know if this is the sort of thing you were talking about when you mentioned "We will need to track

streams associated with sessions, i.e. when they start and stop..."

Chris

PS - this looks prettier if you look at it on the ISAAC web page.

Review of Habanero Streams

Habanero creates a number of streams during it's normal operation. To understand what these streams are,

let's review how Habanero works. Habanero is a client server application. The client starts by creating a

session on a server. The client then requests a socket from the server. This socket contains all the

messages about starting new tools, new people joining, and things exiting and quitting and such.

When the client creates a new tool, it sends a message to the server to create a new tool. And then the tool

is created on the server, and a message is sent to all the clients to create the tool. Usually, the tool is

considered low bandwidth, so it shares the socket that was created for the session. Chat, checkers, and the

soundplayer are instances of this. Some hablets are high bandwidth, such as the whiteboard, and so the

server creates a new socket for each instance of the whiteboard that is created.

The sockets for the session and the high bandwidth clients all contain habanero shared events. However,

some applications, like AudioChat, SoundPlayer, and VideoPlayer create additional streams. These streams

contain streaming data.

How to observe streams

While we are recording, all of these streams are copied into a stream which timestamps the information and

stores the result in a file on the local disk. The file that is doing the timestamps and saving is created by an

ncsa.habanero.replay.ObserverFactory.

If someone wants to monitor the streams, you need to create a new observer factory and then tell the

session to record everything into your factory. You can do this by calling the method:

mySession.setObserverFactory (myFactory, "my-spy-code");

myFactory is an instance of the type of factory you want to monitor the streams, and "my-spy-code" is a

string which identifies your factory. Please don't use the string "recorder" for "my-spy-code" since that is

reserved for actually recording the session. The session can handle any number of observer factories.

The observer factory is required to implement two methods. These are:

createObserver: creates an observer for a stream with serializable objects

createObserverStream - creates an observer for streaming data

Now I'll go into detail about the sockets that each of these receive.

createObserver (String strSessionName, String

strClientName, String strTag) takes 3 inputs. The first is the name of the

session and the second and third tell you something about what information will be in the stream.

You have to return an ncsa.habanero.streams.MarshallOutput object, which is basically an

java.io.ObjectOutput

Here are some of the observers that are created:

strClientName = Session, strTag = Session: This is stream recieves some information

about the version of habanero that is currently running as well as the initial state dump.

strClientName = Session, strTag = Output1: This is the socket that contains the session

level events and all the events of the low bandwidth applications. This is what is sent by

the socket.

strClientName = Session, strTag = Input2: This is the socket contains the first high

bandwidth application socket's input

strClientName = Session, strTag = Output2

This is the socket contains the first high bandwidth application socket's output

strTag = Input3, Input4, ...

strTag = Output3, Output4, ...

These are for additional high bandwith connections

createObserverStream (String strSessionName, String

strClientName, String strTag) takes 3 inputs. The first is the name of the

session and the second and third tell you something about what information will be in the stream.

For these, strClientName is something like "CO2", where CO stands for collobject and the number

is the number of the client - in order that they were created. For instance, if you open the

chatwindow and then open the whiteboard, any streams created by the whiteboard would be

marked "CO2".

strTag contains two parts. The first is whether the information is input or output. The second tells

what tag the hablet has associated with it. This will be application specific.

As an aside, there is an object called ncsa.habanero.streams.NullOutputStream which creates a stream that

ignores everything that is written to it. Sort of a /dev/null of Habanero.

Uses

Clearly, this can then be used to watch during a session how streams are opened and closed. In addition,

this mechanism could be used to observer what is going on in a session and provide some online analysis

by observing the same streams that are saved.

A new feature in Habanero 2.0: The Distributed Replay facility

At the end of the summer, Chris implemented and tested the Distributed Replay facility. To run it, use the Distributed replay option from the Replay menu option in the menu bar.

You can notice that the Replay Editor has not yet been integrated with it. The idea was to habanero-ize the Replay Editor once this one was enough stable to do so.

The following is an extract of Chris's email dated from August 11 1997.

Here is the first installment in "Multiviewer Replay - how to tell the system what to do".

I've added 4 or 5 new actions in ncsa.habanero.replay. You use them like this:

// Set the replay rate

new StandardActionRequest ( new DistributedSpeedAction (1.0 / dReplayRate), currentSession);

You create a standard action request and send it to the current session.

Here are the controls that you have:

DistributedSpeedAction (1.0 / dReplayRate) -> sets the rate of replay

DistributedReplayStart () -> starts replaying

DistributedReplayStop () -> stops replaying

DistributedReplayResume () -> continues replay after a pause

ResumeCollabAction () -> continues collaborating

So, what can't you do yet?

(1) Restart at the beginning of the session

(2) Be updated as time passes

The second is easier, so I'll do that one first. Then I'll see if I can pull off a restart from the beginning of the session.

Chris

I will be very cautious in integrating the Distributed Replay facility as part as a Release Candidate because it has been done in August 1997 and since then nobody touches it. This facility needs to be re-tested with the additions made in the framework since then.

Future extensions

This section regroups all the extensions we (Chris, Zhe, Bin, Lisa, Ed, Larry, Mary and myself) ever thought of adding in the Habanero Capture Replay Mechanisms.

I am going to list them into the following categories: extensions of the Capture Process, extensions of the Replay process, Edition of an archived session, Restart of an archived session, Integration of archived session in the Persistent Object Storage (POS)

Extensions of the Capture facility:

User Time marks.

The user should be able to add his/her own time marks while recording a session. These time marks are automatically labeled by the system, but the user can override this label with his/her own label.

The time marks enable fast and direct access to them during the replay of the session. Internally they correspond to a dump state of the session at the requested time.

I believe we decided that the state dump would be done not during the capture of the session to avoid to slow down the user's machine. Instead, dumping the state at any marks could be done by another program either during the storage of an archived session in the POS, or during the preprocessing stage of the replay of a session. [Lisa's project]

From the GUI perspective, we were looking into two directions to enable the user to add his/her own time marks:

Adding the time slider widget (already existing in the Replay Editor) in the Recording Dialog box to allow the user to add a time mark at the current time or enter time marks at previous times.

This should be coupled with a label box to enable the user to enter a label and/or a description of his/her mark.

Adding the same functionality (adding mark + label box) to the Session Monitor.

In the Replay process, the user marks are going to be shown in the time slider. It is why I would prefer to reuse the time slider as an effort of keeping consistent the marks facility between the Capture and the Replay processes.

I also think that the 2 directions exposed above could be both implemented for the end user comfort.

Extension of the feedback showing that the session is monitored (i.e. REC icon in any session's applications) to display the list of the participants that are currently recording the session.

This list does not need to be shown all the time. So I thought of popping up a list of the participants recording the session when the user click on the REC icon.

Need a feedback on the Habanero Environment itself to show that a session is monitored. Displaying the list of the participants currently recording the session should be expanded to this new facility too.

Extensions of the Replay facility:

Distributed Replay process.

We need to habanero-ized the Replay Editor to make this application collaborative.

I think only the raw of buttons dealing with the Replay functions such as Play, Stop, Suspend/Resume, Fast Forward, and Fast Backward should be shared.

Now, we are going to be able to record a session that replays another one. We should give some thoughts about this new feature.

Implementation of Fast Forward and Backward.

These functions are coupled with User and System Time Marks. [Lisa's project]

Extension in the time slider.

Need to have a zooming function in the time slider to increase/decrease the scale of the time sliders.

New functions to handle User Times Marks such as to display/go to/add/remove/search for a specific label.

If we want to add Users Time Marks while replaying, the state dump process should occur in real time in the Replay Editor… [Lisa's project].

Extension in the Tools area:

To modify the order in which the tools are displayed. To do so, drag and drop a tool around.

To merge several tools in a line in order to compact a set of interactions corresponding to a set of tools.

To highlight the active tool (the one in which the current action is occurring)

To visualize more tools, we thought of reducing the size of each line, or removing/re-displaying some tools from the list of tools.

Extension in the Participants area:

To change the icons corresponding to a user to his/her own picture (small size).

To get a pop up menu for each participant with the same options already in use in the Participant Panel in the Habanero Environment (send email/ see the ID card).

Extension in the Actions area:

To reverse the actions display order on the fly. Now, every action are shaped and colored according to its initiator and sorted by tools. We would like to be able to switch back and forth to the reverse facility : shaped and colored according to the target tool and sorted by participants.

On the first line (the session line), the actions icons should be slightly change to reflect the semantic of the actions (participant joining/leaving action, creation/destruction of a tool).

Edition of an archived session:

Editing a session means rearranging the collaborative Actions that were performed in the session in the following manners:

Changing the content of an action: owner/ text typed in the chat/ etc.

Deleting actions/ Putting them back

Changing the time order of some actions

Adding new actions

These functions should be available for one or a group of actions.

We never looked into this list deeply enough to come up with a clear list of all the problems/solutions implied. But our first remarks were:

Good handling exceptions system during the replay process.

Good help system to manipulate actions.

Undo/redo functions on several levels while manipulating actions.

Need to be able to describe actions and to describe how the actions are related to others.

For this matter, any Habanero Action extends the Describable interface that allows to associate a small comment line to each action.

The following paragraph is a short description written by Chris, to determine Relationship between objects

Relationships between Objects

In order to make it easy to determine which actions, if any, can be deleted. Or to determine what actions are independent, there should be some manner of determining the relationships between actions. This could also help with automated listing, by allowing the programmer to define relationships between actions.

To implement this, an action granted would have a new method, relatedTo, which takes another action granted as input. It returns an enumerated value. The possible values include notRelated, stronglyRelated and weaklyRelated. There might be a range of values used to determine how strongly related two actions are.

The default effect will be to return stronglyRelated if the two actions are to the same object and the current action granted is immediately before the next action granted.

The user can override this default relationship, by having the action that the action granted contains implement the interface c. This would take five inputs, the serialized number of each action, the destination collobject of each action, and the other action.

An AppletAction would immediately pass this on to the events, and return the default relationship if the event didn't implement the Relatable interface.

Some examples:

Checkers would implement the default relationship, since each action depends on the previous action.

WhiteBoard would have strong relationships when an action creates an object, and the following movements of the object. It would be weakly related, if the drawn objects intersect at some time, or were shuffled front to back.

Chat could be said to have no relationship between actions, since removing one changes the meaning of the conversation, but isn't required.

Strong relationships could be represented by a solid line. Weak relationships by dashed or dotted lines.` And no relationship by no line.

Notice that this allows people to define more powerful relationships, for instance between people talking about a circle in the chat window and people actually drawing or manipulating a circle in the whiteboard.

The permissions to edit a session in order to give access or restrict the rights to edit a session.

These rights should be more refined.

Collaborative Editing.

Will Editing a session be a multi-user or single-user facility?

Extensions in the Tools Area

To remove a tool.

Need feedback -- should be permanently displayed to be able to undo the deletion) / put it back

Restart of an archived session:

See next section.

Integration of archived session in the Persistent Object Storage (POS)

Store/load captured or/and edited sessions.

Search for meta-data associated to archived sessions.

Import/Export archived sessions.

Publish archived sessions on a server and notify people interested in them.

Merge archived sessions into a live session

Branch archived sessions

For more details, read Mary's white Paper: "Synchronous/Asynchronous bending in Habanero" available at http://ripcord.ncsa.uiuc.ed/hab_docs/hab_sync_async.shtml

The Session Monitor

The Session Monitor is an extension of the Replay Editor to display live sessions. Our motivation was twofold:

First, we wanted a more dynamic view of a live session than the one given by the Habanero Environment. In fact, reusing the Replay Editor enables us to see in real time "who is doing what in what tool": the Session Monitor gives us a better view on the focus of attention of any participants in the session.
Our second motivation was to reuse the Replay Editor facility to provide the same view and functionality for live or archived sessions. For a full description of the User Interface, refer to the "User Guide For the Capture Replay Mechanism in Habanero 1.0" paper (http://it.ncsa.uiuc.edu/~chabert/Doc/CR_Guide.doc).

In the following, I will report the major differences between the Replay Editor Habanero 2.0 and the Session Monitor.

Launching the Session Monitor

The Session Monitor is a single user tool available from the Habanero Environment. This application displays only one live session. If you want to see more than one session at a time, you have to run several instances of the Session Monitor for each session you are in.

I believe the command to launch this tool is under the Session menu from the menu bar. I think/hope Bin would have let some documentation about this before he left

Here, there is no loading phase required at the launching of the tool. In fact, every bit of information is not preprocessed as in the Replay Editor but everything is processed in real time. For that, Bin extended the Serializer Class to have more knowledge on the actions transmitted (initiator of the action, time of occurrence, target tool, etc.).

The Time area:

The time scales display the session from the beginning and are automatically increased. The time slider is also automatically moved as the time goes.

The Tools area:

The Tools area regroups all the tools ever created in the session. Few functions were added to take into account the dynamic of the process such as:

Adding dynamically a new line for a new tool.
When a tool is closed, the associated line is from now and then gray out.
Etc.

The Participants area:

The Participants area was modified to display the picture of the participants instead of the shape/color pictogram. Moreover, via a popup menu you have access to the same functions as in Participants Panel in the Habanero Environment (Email a participant/ display Id Card/ beep me).

The Actions area:

The actions are created on the fly when they occur. And they are now associated to the picture of its initiator.

No more Modes area.

Future Plans:

Compacting the Session Monitor and the Habanero Environment to avoid the duplication of the Participants and Tools lists.

Developing the GUI to be able to make User Times Mark in the Time area.