Digital Space Commons: Welcome to Meet2D

Meet2D Java Thin Client Edition

Chat Logging Explained

OWORLD/CLIENT 2 SERVER CHAT LOGGING

BRUCE'S ORIGINAL REQUEST

a) new parameters to help in meeting recording, such as:

<param name="assignFileLog1" value="meetinglogs/digis-meeting1.html"> creates an association to a log file at the given address on the server and assigns that to the symbolic ID Log1. You could have more than one log file assigned to these addressible IDs such that different javascript or bot controls could write different elements to separate logs. For example, one logfile (ID) could record a whole meeting, and another a filtered set of notes like "dear bot take this one liner note here" and off it goes to LogFile2.

<param name="setAccessLog1" value="append"> will cause the Oworld log writer to append to the log file defined by assignFileLog rather than overwriting it (the default if this parameter is not set). This will allow the creation of a long term log that crosses sessions. Care has to be taken here as you dont want the exposed method onLogCommence to give you HTML header tags back when you are going to be writing mid-file. That is why the append setting is also passed to both onLogCommence and onLogComplete exposed methods (see below). Now if the applet determines that the log file does not indeed yet exist, then this append condition is ignored and not passed to any exposed methods below.

<param name="setModeLog1" value="startup"> would direct the applet to immediately "commence" logging on startup. In this case the exposed method onLogCommence is called immediately on ChatPanel initialization, to get the commencement string back and the file is created and/or written to. Following this, processLogText methods are called for every string entered as chat.

New Applet Exposed Methods for JavaScript: controls processing of text logs
(basic question here: is JavaScript efficient enough to do this kind of string processing for the applet?)

a) an exposed method "logControl" that could be accessed by JS to request Oworld to "commence", "pause" and "complete" recording to a given log file of ID defined in the above parameters (logControl is used for run-time UI-based control of log recording rather than the automatic startup logging of setModeLog). When the method is called to pause recording in Oworld, strings are no longer passed out the to the method processLogText and the method onLogPause is called. When this method is called to complete logging, Oworld will call method onLogCompletion and close the file on the server.

b) another exposed method "onLogCommence" that is called once by Oworld, when a Log process of a given ID is "commenced". This method has a chance to get a string back from the JS attached to the method. That string could be anything, including the date/time of the log (for a simple text log) right up to good old HTML header tags to format the log file. Note that if the parameter setAccessLog is set to "append" then a parameter to this effect is passed out through this method. This allows onLogCommence to create a "middle of the file" formatting rather than expecting the file to be at the top.

c) another exposed method "onLogPause" that is called once, when a Log process of a given ID is "paused". This method also has a chance to get a string back from the JS attached to the method. That string could be anything, including a note to write to the log saying "logging paused at [time]" or good old HTML footer tags to record the pausing in an HTML-formatted log file.

d) another exposed method "onLogComplete" that is called once, when a Log process of a given ID is "completed". This method also has a chance to get a string back from the JS attached to the method. That string could be anything, including good old HTML footer tags to complete an HTML formatted log. Note that if the parameter setAccessLog is set to "append" then a parameter to this effect is passed out through this method. This allows onLogCommence to create a "middle of the file" formatting rather than expecting the file to be at the bottom (and to terminate the file). onLogComplete is called on applet closure to permit shutting down of log files. Log files should be closed by the applet after writing this last string.

e) yet another an exposed method "processLogText" that, when logging is in a "commenced" state, Oworld will then be directed to export each line of text entered into the chat buffer out to running Javascript attached to processLogText. Along with the text, the ID of the log file is passed to allow the JS to switch to different processing for the text. If more than one log of unique IDs are defined and "commenced" then the JS could be called twice, with the same text for each ID (or both IDs passed to the JS via the method). This JS could then be free to process the given text with its own logic and pass it back to Oworld, along with the log ID. In this manner we give a JS "logger bot" the ability to process and possibly filter out or format (by inserting HTML tags) any entered chat. If the JS passes the string back in it is written to the log file of the given defined ID. The JS might not pass this string back at all, in which case it is not written to the log (allowing filtering of meeting logs, so that, say, only a certain citizen's text is actually saved. This all allows the website designer to have control over how the logs look, using basic primitives and the power of JavaScript. Note that all text written to logs is assumed to have a carriage return and linefeed at the end of each returned text string. Also, text passed by Oworld to processLogText will contain user names, entered text gestures and anything else that appears to the user in the chatpanel. Welcome messages and any bot or system message will also be sent to processLogText.

That should do it for the total interface to create wonderful logs! Now for some examples:

APPLET PARAMS:
"assignFileLog1" value="meetinglogs/digis-meeting1.html"
"setModeLog1" value="startup">

RUNNING THE EXPOSED METHODS
setModeLog1 sets the applet running, the applet tries to open the given file. If it errors on this step then an error message is reported and an internal vaiable set to ignore (or warn on) all attempts to log. If the file is accessible, Oworld immediately calls:
onLogCommence with ID Log1 which returns the following example HTML header string: <html><head><title>Log for Campbellsan's Conference 2/24/2001 4:35pm</title></head><body bgcolor="#FFFFFF">

and then as each line of text is entered into the chat, Oworld calls:
processLogText which processes each line of text, for example:
input: "bd: dont panic Campbellsan, this will be powerful yet simple"
output:  bd: dont panic Campbellsan, this will be powerful yet simple
to be written to the file.

and when the applet is closing or an exposed JS interface to "complete logging" (if any) is pressed..
onLogComplete is called and generated the following string back for writing: Log of meeting finished 2/24/2001 5:15pm </body></html>

So in the end the logfile looks like

meetinglogs/digis-meeting1.html
<html><head><title>Log for Campbellsan's Conference 2/24/2001 4:35pm</title></head><body bgcolor="#FFFFFF">
 bd: dont panic Campbellsan, this will be powerful yet simple
Log of meeting finished 2/24/2001 5:15pm </body></html>

WHO SHOULD RUN CHAT LOGGING?

Which instance actually logs the chat? Well we have a problem, as we are not recording chat on the server side, and allowing the client to do all the processing and saving of logs (pushing the flexibility out to the webmaster and javascripter) then we have to allow ONLY ONE RUNNING APPLET to record logs back to the file on the server. That means that MP or the webmaster must generate a CHAT LOGGING VERSION of the applet parameter+JS controls for only one user. That user could of course be the "caretaker", "moderator" or any other designated chat logging client. This can be INVISIBLE to the users as long as there is only ONE applet logging. Of course maybe one applet logging to a file on the server will LOCK that file and cause errors in an erroneous applet also generated to log. And also, another applet may be logging to a completely separate file, which is actually OK! Best to leave this flexible, team, and see if we run into any probs.

Whispering and privacy in logging

What is logged? If logging to a file, whispers between individuals should not be logged even though they appear in a users' private log window. This protects private conversations from inadvertantly being made public later. An option to log whispers may be added later, as long as this is known to the conversants.

The CONCEPT OF A CARETAKER.. that is for.. next time!

CAMPBELLSAN'S INITIAL IMPLEMENTATION

Hi Thinners,

An update on the chat logging interface:

Until we implement the caretaker parameters (next week?!?!), I have
simulated the caretaker role through a separate URL. If you connect to:

http://www.meet3d.org/dev/content/anfy/build028/chat_c.html

you will have simulated caretaker rights to logging the chat session that
ensues. If you connect to:

http://www.meet3d.org/dev/content/anfy/build028/chat.html

you will not have the ability to log the session (since you aren't the
caretaker).

Currently, I am simulating the server side logging file through a Java frame
(appears in the upper left of your screen). So, you can see exactly what
will be logged to the log file once we open, read, write, and save files on
a server.

You will see three new applet parameters on the chat_c.html HTML doc
(suggested by Bruce):

<param name="assignFileLog1" value="meetinglogs/digis-meeting1.html">
<param name="setAccessLog1" value="append">
<param name="setModeLog1" value="startup">

The assignFileLog1 parameter points to a file on the chat log storing server
(where the open, read, write, and save actions will happen).

The setAccessLog1 parameter suggests how the latest chat session should be
logged relative to the current file (if any) stored with the assignFildLog1
name.

The setModeLog1 parameter suggests when the logging should start (which in
the example above is immediately upon loading the applet). I have also
implemented a value of "ondemand" which won't start the logging until you
click on the Start button (see the HTML based buttons).

The chat_c.html HTML doc has four buttons related to chat logging:

1. Start - starts the chat log session unless the chat log session has
already started. In that case, it just shows the chat log frame window.

2. Pause - pauses chat logging.

3. Resume - resumes chat logging. (could be combined with the pause button
in a nicer looking interface)

4. Complete - ends the chat log for that chat session.

Go ahead and try the above out. I can run quite a few chat applets
simultaneously on my machine at work or at home. I understand that is not
the case for all of you though. I am going to work on lowering thread
priorities and synchronizing the OWorld chat method calls even tighter that
they currently are.

So, bare with us as we bullet-proof our Meet2D and Meet3D clients.

Lastly, I've been thinking through the last message I sent to Bruce and Stu.
In reading Bruce's chat log missive once again, I now think that it is
saying that JavaScript will be able to write directly to a server file. That
sounds really cool. I just need an example of how that works. If no one has
an example, I will do the research myself.

Back to Support Index