Minutes, Meeting of Wednesday, 27 May 1998

Minutes taken by Hilary Mason. Modified by Sam Rebelsky.

The meeting began at approximately 1:30 pm in the MathLAN laboratory.

Notebooks:

• Front: table of contents
• Back: timelog with date, time start, time finish, interruption time,
• Total time, activity, comments, completed, units
• Always date pages.
• Number each page in the notebook to make it a legal record of work.

Mr. Rebelsky found the information on project Clio, link from today's agenda. Clio is the result of brainstorming on this topic, with survey form and list of responses, may not be useful but it's there.

We read two different papers yesterday. Tradition in academic paper writing: try to write as little new each time. MacSQEAL was more useful because it was a more in-depth look than "The Pursuit of Knowledge". PoK said more about why we are gathering this information, and why it is useful.

No new ideas from rereading the proposals.

Not very much else applicable from the readings. We should have an easier user interface than MacSQEAL. Overlays, charts, ups and downs would be nice. They dealt with multiple log file types. We will need to think about this.

A goal for today was to think about log files. Sarah doesn't know how we're going to keep the time in the MacSQEAL type format. This means we'll have to change it. Kevin thinks we should do one log file per person. that way, if the file is messed up, we only lose that person's data. We would record pages accessed, time, where they came from, where they're going... We should distinguish between people going in and out of our web and people travelling within the web. We're going to ignore the normal HTTPD logfiles and build out own.

Log Files

• One per user, to decrease chance of corruption (an alternate is one per session)
• One possible format is: Absolute time, page, source, destination
• After some discussion, we arrived on
  • user
  • session #
  • window ID
  • absolute time
  • event type
  • additional information (if appropriate)
• The possible events are
  • leave web + destination
  • enter web + source
  • load page + page
  • still on page + page (how often is this reported?)
  • observation about javascript
  • java/javascript is not on!
• Should these files be human readable? We decided no. We'd use one long per entry in the file, with many entries being indices into auxiliary files.

While it was hoped that the "one file per user or session" might ameliorate the need for locking, the need to handle multiple windows (and the auxiliary files) suggests that we still need to worry about such things.

If there are two Netscape sessions, one might (1) Create new session? (2) get window ID (3) infer from "still on page". It is likely that we will do the third.

Ethical Implications

We need to consider what the less personally intrusive ways to use our system will be, and who will decide what types of access are allowed For example, do we allow anonymous users and unlogged users?

We should read the guidelines about experimenting on human subjects.

How do you get information?

We spent a little time reviewing some of the mechanisms we can use to determine the information that we will log.

• We can run a CGI script when a page is loaded. A CGI script can get any time, the source page, cookies, and query strings that we might desire.
• We could have Java applets in our pages. These applets can basically send information back to the server, such as "loaded", or "on a page". It can communicate with Javascript.
• Another neat thing we can use is Javascript. With this we can get cookies, query strings, environmental issues (such as window ID)
• It's also possible to have the links on a page go to a CGI script that then forwards them elsewhere (but not before sending information to us). We'll have to worry about the back and forward buttons.
• Server Side includes are also a possibility, but it doesn't seem likely that many people (including us) can use them.
• We could write a plug-in that sends all of the information.

We may be reinventing the wheel for some of this, but at least we'll know not to make it square.

The Architecture

We'll start with someone's regular HTML files. One possibility is that the user always goes through a CGI script to get to these pages, and this scripts inserts java/javascript and modifies links. Example: <a href="kevin.html"> becomes <A href="a href=clio.cgi?page=kevin.html">

• + This even works for nonlocal pages,
• + and is quite compact.
• + the changes are reflected immediately.
• - This creates ugly (and not very useful) URLs.

An alternative is that we create a "compiler" that turns the HTML files into either "improved" HTML files or CGI scripts.

• - With this system, the pages may have to be recompiled whenever they are changed or added.
• + the URLs are reasonable
• - potential processing at load time
• - increased processing time (so Mr. Stone gets mad)
• - effect on page load time

To support better understanding of these architectures, we developed a set of Overly ambitious goals for tomorrow.

Write a version of clio.cgi. Kevin does this in Perl and Raphen in Java. Write a little compiler that takes and HTML file with text to put in head and body and does that. Hilary does this in Perl and Sarah in Java.

Kevin demonstrated how to run a Java program as a CGI script using a front-end written in either bash or perl.

The Java File

import java.io.*;

public class JavaCGI {


  public static void main(String args[]) throws IOException {
    
    System.out.println("Content-type:text/html");
    System.out.println();
    System.out.println();
    System.out.println("<html>");
    System.out.println("<title>Hello World</title>");
    System.out.println("<body bgcolor=white>");
    System.out.println("<center>Hello World</center>");
    int i;
    
    for(i=0;i<7;i++) {
      System.out.println("<center>"+args[i]+"</center>");
    }
    System.out.println("environment");
    System.out.println(System.getenv("HTTP_USER_AGENT"));
    //System.out.println(env);

    System.out.println("</body>");
    System.out.println("</html>");
  }
}

The Bash Front-End

#!/usr/local/bin/bash

/usr/local/java/bin/java JavaCGI lalala

The Perl Front-End

#!/usr/local/bin/perl

 $date = `/bin/date +%m-%d-%y-%Z`;
 $userAgent = "$ENV{'HTTP_USER_AGENT'}";
 $RealUser  = "$ENV{'REMOTE_USER'}";
 $ServerSoft = "$ENV{'SERVER_SOFTWARE'}";
 $Server   = "$ENV{'SERVER_NAME'}";
 $RemHost  = "$ENV{'REMOTE_HOST'}";
 $RemAdd   = "$ENV{'REMOTE_ADDR'}";

system '/usr/local/java/bin/java', 'JavaCGI', $date, $userAget, $RealUser,
  $ServerSoft, $Server, $RemHost, $RemAdd