At the outset of the sniffle project, I began to record each day's work in a log file. This file, listed below, provides a fairly complete account of the evolution of the project. It also contains lots of information about product vendors, ``gotchas'' that I encountered during the development process, and anything I considered worth writing down.
Log of activity on remote control via Web project with Prof. Littman.
Author: Terence Kelly <tpkelly@phoenix.princeton.edu>
RCS File: $Source: /u/tpkelly/littman/RCS/log,v $
$Revision: 1.9 $
6/6/95 Meeting with Jay Lieske and Kirk Alexander in ICGL
They recommend hardware encoding of MPEG. Mention IRIS "InPerson"
software for SGI machines. Names of CIT people who have clue:
Kevin Perry (Mathematica instructor), Dave Harrington (CU-SeeMe
experience). Names of other people with clue: Ken Stieglitz,
Bede Liu (image processing professor).
Littman discuss funding with Diane Balestri.
Suggest net search of "CU-SeeMe", "Live Video", "MPEG". See
Netscape page for server push/client pull.
Basic idea that emerged was to have two parallel systems solve
different parts of the problem: Use Web to transmit initial
conditions from client to lab-based server and to start
experiment. Meanwhile a separate system handles video feedback
from lab to client end using perhaps CU-SeeMe.
6/7/95 Met with Littman in lab. He approves of idea of two parallel
systems for instrument operation and video feedback. I said
I'd perform appropriate research.
6/8/95 Wrote Ted Nadeau asking for MPEG etc. advice
Faxed and snail-mailed to many many companies from magazine of
Kirk Alexander requesting MPEG hardware info etc.
Set up mail-logging scheme. Mail littman instead of mlittman
to log mail to ~tpkelly/littman/mbox.littman file.
Brief bobw on HTML and LaTeX
Surf net looking for httpd server info. Looks like Netscape
requires Windows NT. No mention of Linux among flavors of
Unix compatible with Netscape server.
NCSA mentions Intel-based PC at URL
http://hoohoo.ncsa.uiuc.edu/docs/setup/PreCompiled.html
Windows and Windows NT httpd at URL
http://www.yahoo.com/Computers/World_Wide_Web/HTTP/Servers/
Windows___Windows_NT_HTTPD/
Cool Windows (not NT or 95, just Windows) server URL:
http://www.city.net/win-httpd/
Wrote to rdenny@netcom.com about above server, asking minimum
hardware requirements.
6/9 Got reply from rdenny, who says "A 386 should be fine, as long
as it has 4MB or more of memory."
CGI-DOS, helps you use Perl with Win-httpd, URL:
http://www.achilles.net/~john/cgi-dos/
Download Bob Denny's Windows httpd .zip file. Note the
directions on installation (we need recent PKUNZIP):
"Create a directory c:\httpd (don't be creative yet!),
and unzip the kit, using the PKUNZIP "-d" option to
preserve directories. Then open the file
C:\httpd\htdocs\index.html with your browser and read
it. Once you have gone through the checklist, start
the server and access it as http://1.2.3.4/ where
1.2.3.4 is your PC's IP address. Try out the demo
page. If the server exits immediately, look in
c:\httpd\httpd.log for the reason."
Found CU-SeeMe page: http://cu-seeme.cornell.edu/
Sunday June 11 Dartmouth will broadcast a CU-SeeMe video of
Bill Clinton's commencement speech:
HTTP://picard.dartmouth.edu/~oly/BillVision.html
There's a reflector at U-Penn, IP address 130.91.72.36,
according to Dartmouth docs.
CU-SeeMe Windows system requirements:
http://cu-seeme.cornell.edu/supportedwin.html
(looks like 386DX will suffice, but cheapest video board
will cost around $350)
Remote control on the Internet:
http://www.indstate.edu/msattler/sci-tech/comp/
misc/remote-control.html
CU-SeeMe User's Guide:
http://www.indstate.edu/msattler/sci-tech/comp/CU-SeeMe/how-to.html
6/10 Install CU-SeeMe on OPR PC in anticipation of Clinton Speech.
Connected to U-Penn reflector and caught glimpse of video broadcast.
IT WORKS!
MBONE FAQ at AT&T: http://www.research.att.com/mbone-faq.html
6/11 Watched Clinton speech at Dartmouth. Very disappointing.
At best got 1 frame per second. Average was around 0.5 fps.
Worst was 0.1 fps. Don't know source of bottleneck.
6/14 Talked to Littman. He found interesting new Web page on remote
controlled CU-SeeMe camera:
http://www.hiof.no/ludvigsen/webdoc/pt/pt_dummy.html
He said I should start to configure httpd server on 386 on
cart, not to touch Robert's 386 unless other one is short of
disk space. Our 386s have microchannel architecture, not
EISA. The one on the cart has a phone-jack type ethernet
connector, Xoftware and Novell Winsock (?). It's a PS/2
Model 80.
Phone numbers: G-101, where "George" often is: 5567
Littman's office: 5198
FTP'd Windows HTTPD and pkunzip.exe to C:\httpd\ on 386
on metal cart. That machine is a nightmare. Slow, poorly
connected, software not configured properly (Xoftware is
particularly uncooperative). Tried to pkunzip -d per the
instructions but ran out of disk space. May have to do this
on Robert's PC.
6/18 On 6/17 or thereabouts installed WinHTTPD on D:\ partition of 386
machine on cart in G-101. Configuration was a hassle because the
httpd assumes you're installing on C:\, not D:\. But it works
and successfully served a "hello world" document for over 24 hours.
The URL is http://douglas.princeton.edu/.
6/19 Installed Netscape on two more PCs in G-101 (previously installed
it on 386 on cart). Installed VBRUN300.DLL in C:\WINDOWS\SYSTEM
on 386 on cart. Tested server: all features other than imagemap
now seem to work properly. CGI-DOS and Visual Basic CGI stuff and
Windows CGI stuff all seem to work. Had to edit PIFs for some DOS
stuff to make it all work and make error messages go away. Server
is still up and running as of 10:53 a.m.
6/24 Got "hello world" program to compile on Robert's PC and emit
digital output to DVM via RTI-205 board and STB-50 connector
cable. Program toggled voltage across outputs between 5.04 VDC
and 0.033 VDC.
Problem 1: Could not compile a hello program on PC on metal cart
where server is because compiler complained about DECL.TPU
unit, even though I copied it directly from RTI205 directory,
and then from Robert's C:\TP directory, where it worked. I
think the problem may be that metal cart PC has later version
of Turbo Pascal (a downgrade).
Was able to compile a HELLO2.EXE on Robert's PC and then run
it on my PC, but it didn't produce the proper range of output
voltages: output voltage oscillated reliably between 4.23 VDC
and 4.37 VDC at correct times. Problem with STB-50? RTI-205?
7/6 Met Littman at noon and discussed plan for future. Here is current
plan:
1. Client submits amplitude parameter to
server, which passes parameter to batch
file or one program therein.
2. O-scope begins to read & record data.
3. Pascal program gets amplitude parameter
passed by client, outputs that voltage.
4. Everybody waits for a while.
5. Data is read from O-scope to file on server,
then returned to client in native .WFM format.
6. Data is displayed at client using 222UTIL\VIEW.EXE
Sal Desiano gave me numbers for Analog Devices company (makers
of RTI-205 board):
Main 617-461-4111
Regional 215-643-7790
Tech. Support 800-262-5643
Sales 617-461-4194
At noon demo'd to Littman activation of "Hello, World" program
on server PC from Netscape client (the program output an analog
voltage via the RTI-205).
In evening played with Tektronix 222 O-scope. Idea: use Tektronix
utility VIEW.EXE (in C:\222UTIL) to view data captured by scope at
client end: server transmits a .WFM ("waveform") file to client
with new MIME type e.g. "application/waveform", and client spawns
local copy of VIEW.EXE to view it.
7/8 Yesterday and today tested idea of using VIEW.EXE as Netscape
helper application -- it works from my PC at OPR. It causes
Netscape to issue a "floating point error: stack under" message
on G-101 PS/2, but this is obviously not a problem with the basic
idea.
Bill Vinje told me about "Lab View" -- a GUI for lab equipment
interfaced to PCs, and about a standard protocol for communications
beteween lab instruments and PCs called ??? (I forget) which allows
a PC equipped with a special board to talk to a daisy-chain/bus of
o-scopes, etc.. Must ask Littman about this.
Must call Tektronix and ask them for latest PC, Mac and X versions
of VIEW utility.
7/9 Got following scheme to work well with RC circuit that operates on
human time scales (using roughly 10 meg resistor and .22 uf cap):
Client submits voltage, delay1, delay2. Server activates Pascal
program that drops output voltage to zero, waits delay1, raises
output to voltage specified by user, waits delay2 sec., drops
voltage to zero.
Can't get batch file that invokes above Pascal program to follow
it with a GETWFM.EXE call -- resulting waveform file is empty.
Possible solution: have Pascal program talk to oscilloscope to
get waveform, rather than GETWFM.EXE.
7/10 Met with Littman in G-101 to demo above.
7/11 Looked at Tektronix ftp site ftp://ftp.tek.com/mbd/support
where lots of utilities for 222 scope live. Unfortunately none
of them are newer than the ones we have.
We should perhaps use TOADIF utility to convert .WFM files to
.ADF format at server end, and view with WAVIEW at client end.
May be difficult in any case to get client-spawned viewer to
display two scope traces easily.
Problem: disk space is running low in lab.
7/17 Lately have had problems with RS-232 interface to Tektronix 222.
Want to write little program to send command-line arguments to
scope and write whatever comes back to standard output. This
program CAN send strings like "BUT 1" to scope and scope usually
responds appropriately. But a run-time hardware error (usually
code 162) occurs when attempt to read from scope.
Called Tektronix customer support at 1-800-835-9433 x2400 (got
the number from WWW page), spoke with Dave Frazel at x3028. He
said problem might be our firmware version: we have version 2.16
whereas latest version is 3.8. He said he'd have one of his
software people call me later today. The Tektronix customer support
line is open 6:00 am to 5:00 pm Pacific Time. Tektronix customer
support e-mail: tm_app_sup@tek.com.
Spoke with Ed Lingell about problem with 222. He wants to know what
the error code means. He said Tektronix doesn't have source to
222UTIL stuff. Fellow who wrote it left company.
Later spoke with Tektronix Dave Nelson, who suggested that a
"handshake error" might be responsible -- handshaking is set on the
RS-232 board on the PC, in part using the DOS mode command. The
settings that Nelson uses with Windows terminal are: CRLF, No parity,
8 data bits, 1 stop bit, no parity check. Nelson also gave me the
number of Cal Diller, who wrote the 222UTIL stuff, and is now working
for "Metro Tek": 503-640-4906.
Firmware upgrade: Washington DC service center (800-962-9738) says
they don't handle 222 scopes. Referred me to Beaverton OR factory
service (800-835-9433 x2400). Also gave me Ship To address:
Tektronix, Inc.
Attn: Factory Service, M/S 78-576
Regional Distribution Center
Beaverton OR 97077
Still waiting for pricing info on firmware upgrade from Tektronix.
Spoke with Barry Long of Analog Devices, requested info on all
RTI-205-like products. He said recent versions of drivers are
available from BBS: 617-461-4361, 8 data bits, 1 stop bit, no
parity, 1200-9600 baud. Barry Long is an application engineer,
his number is 617-461-3090. Application support is 617-461-4111.
Spoke with Cal Diller, author of 222UTIL stuff. His number at
Metro Tek is given above, his e-mail is 71662.31@compuserve.com.
He is VERY helpful. Said he'd mail me the source to 222UTIL stuff.
Said in order to handle COM port well would have to write interrupt
handler to deal with interrupt that occurs whenever the SINGLE BYTE
of COM port buffer is written. 222UTIL things do NOT have an
interrupt handler, just continuously read from port in tight loop.
Said there is a Pascal command to get a character from the COM port.
Said Visual Basic includes routines that do interrupt handling.
Visual Basic is the way to go, says he. Recommends book, "The C
Programmer's Guide to Serial Communications," by Campbell, published
by SAMS. This book contains assembly code hardware interrupt
handlers.
Can also write Windows DLLs in C/Pascal to use Windows interrupt
handlers, and these can be called from Visual Basic.
Diller said he could give me source to API he wrote that lets you
talk to instrument via hi-level commands, it runs as DLL and requires
Visual Basic variable-length strings. Visual Basic costs $299 at
Programmer's Paradise; Borland Delphi is $99, similar to Pascal.
Finally, Diller recommends National Instruments and their Lab View
product: 6504 Bridge Point Parkway, Austin TX 78730-5039,
512-794-0100.
7/19 Installed Visual Basic on PC AT with 486 upgrade & 4 megs RAM.
Have not tested yet. Wrote Cal Diller to ask if he knows about
reading COM1 using Visual Basic. Documentation is silent about
this.
7/21 Ordered MS Visual Basic Professional Edition thru CIT MDC,
Nina Moyer 8-6798. Will deliver tomorrow (Saturday) to Littman
home. Charged to account 150-1009. MDC orders from a company
called "Ingram Micro" in or near Buffalo NY. Ingram Micro sales
is 800-456-8000, customer support is 800-274-4800. They must
receive an order by 3 p.m. to ship that day. MDC is 8-5566, open
M-F 10:30-4:30 (at least at this time of year).
Egghead software in Lawrence was not helpful, could not get us
product with educational discount. MDC price is $90, Egghead is
$340.
Spoke with Wally Schwanke of Tektronix, 503-627-6630 regarding
firmware upgrades. He said Tektronix now has 5-day tunaround time
from time of receipt of scope to time of return shipment. He will
investigate cost of upgrade and call back with info.
Nina Moyer of Microcomputer Distribution Center placed order of
MS Visual Basic Pro, should be delivered to Littman home tomorrow.
7/23 Installed Visual Basic Pro, tested MSCOMM.VBX control. It works
well.
7/24 Cal Diller's package arrived containing a diskette. Diller's
post-it note on diskette says "I think the functions you want are
in LIB\ASYNCXX.C". I copied the files on the diskette to
C:\TPK\DILLER\ on my PC at work.
Also in Diller's package is a description of product by Diller's
company, Metratek (503-693-1607): Waveform Manager Pro ($199).
Will talk to 222 scopes, write GIF files. But can it be made to
run in batch mode? Maybe using Visual Basic! Will ask Diller
when I write to thank him.
7/25 Talked to three third-party vendors who make software for RTI
series boards. DSP Development dude had little clue, said he'd
send literature. HEM Data Corp sells boards, fully supports the
815 board, will send literature. LABTECH dude Brian Harrington
was clueful & helpful, told me about LABTECH product Notebook (Pro)
for data acquisition & talking to boards. Has some sort of macro
feature called "batch runner" which sounds like exactly what we're
looking for. Will send literature on products including educational
discounts and bulk discounts. Phone numbers:
DSP Development 617-577-1133
HEM Data Corp. 810-559-5607
LABTECH 508-657-5400
I found out about these companies in the Analog Devices catalog.
Spoke with dude at DSP (toll free 800-424-3131 x400) who explained
that their current products are more oriented toward data analysis
rather than acquisition, therefore not appropriate for us.
7/27 Wally Schwanke of Tektronix (503-627-6630) said we could possibly
get firmware upgrade for free but would require more details on
how we got the scopes. Litman said Tektronix approached him around
1987 and offered to donate fancy equipment, he wrote up proposal,
Tektronix gave us a dozen 222 scopes and one color printer. He
was disappointed by what they gave us, wanted more. Gift came from
"Signal and Measurement Division" or "Test and Measurement Division."
Gift was in support of science education. Littman said could obtain
copy of his proposal from Mary Lavin of MAE (melavin@pucc, 8-5127)
or Anna Faiola. I wrote Mary Lavin at PUCC to ask for proposal.
GREAT IDEA: For dealing with all RTI board issues, simply write
an INTERPRETER in Turbo Pascal or whatever that takes a text
stream of commands and makes the RTI board do its thing based on
those commands. E.g. if it gets a line that says "DOT 161" it
tells the RTI board to output binary 161 on its eight digital
output wires! Presto! We then have a LANGUAGE that can be
transmitted over the Web that causes the RTI board to do ANYTHING
it can possibly do!! Damn I'm good.
7/28 Got Visual Basic program with no forms whatsoever to run and
respond; it returned something to the client. The thing to do
is to have NO FORMS WHATSOEVER in your project. Use ONLY code
modules, per R. Denny's suggestion in WinHTTPD documentation.
Have a subroutine "Main" in one of the modules and designate this
as the first thing to happen upon program execution.
Asked Littman about software & manuals for RTI-815. He authorized
me to buy $120 worth of them from Analog Devices.
8/4 Purchased documentation, software and screw terminal board with
ribbon cable for RTI-815. Tested board with EXER utility and
DVM, found that analog outputs work. Modified Visual Basic
sample program, tested it, found that it works. We get two
analog outputs and possibly eight digital outputs. Have not
yet been able to get digital outputs to work.
8/5 Digital outputs don't work because they operate off a SECOND
set of output pins from a 34-pin J1 jumper in the middle of the
RTI-815 board. Must purchase this ribbon because we need
digital outputs.
One place to start looking for the GIF format spec is at
http://www.cis.ohio-state.edu/hypertext/faq/usenet/graphics/
fileformats-faq/part3/faq.html
Here's what that document has to say about the GIF format:
GIF is a data stream-oriented file format used to define the
transmission protocol of LZW-encoded bitmap data. GIF images may be up
to eight bits (256 colors) in depth and are always compressed. Despite
the fact that GIF supports only 8-bits worth of colors, and the
multimedia extensions introduced in the 89a release have not been
widely utilized, GIF still remains a popular choice for storing lower
resolution image data.
The GIF89a specification is available via many BBSs and on-line
information services. You may also obtain the specification directly
from CompuServe:
CompuServe Incorporated
Attn: Graphics Technology Department
5000 Arlington Center Boulevard
Columbus, OH 43220
Voice: 614.457.8600, 800.848.8199
Lots of GIF utilities, plus a .ZIP file containing the format,
are at http://ubu.hahnemann.edu/SimTel/gif.html.
The format spec itself is at
http://documents.cfar.umd.edu/imageproc/gif89a.doc
8/8 Ordered two proper 34-pin female J1 plugs (one with, one without
polarizer) and ribbon cable from Master's Electronics in Raritan,
908-725-3533. Will be shipped today via first-class mail, arrive
later in week, charged to my credit card. Cost will be under $15.
Fellow at Master's Electronics says that for LED hex readout of
TTL lines, need 9368 chip (around $7 each) and 7-segment hex LED.
He will see if he has pinout documentation on 9368 chip. Will take
at least 2 weeks to order.
Littman hooked up his own hex LED displays for me, so no need to
purchase. Tested digital outputs and they work well. Pinouts on
hex LEDs are worth recording, because they're unusual:
________
Vcc 1 | _ | 14 Vcc
bit 1 2 | |_| | 13 bit 2
bit 0 3 | |_| | 12 bit 3
4 | | 11
GND 5 | | 10
6 | | 9
GND 7 |______| 8 GND
8/10 Ordered from Free Software foundation Windows gnuplot diskette
for Littman project; Texinfo manual for me; DJGPP CD-ROM and DOS
utils diskettes for OPR. All should arrive via FedEx tomorrow.
Littman says re: Analog Devices bill to call purchasing, get PON,
then have Analog Devices re-bill me. Call "Helen" in MAE if
problems; she works in a.m. only. We didn't discuss FSF software
(gnuplot for Windows) or $10 for J1 parts.
Littman and I added COM3 and COM4 ports to 486 PC; will use COM3
for Tektronix scope. Also replaced homebrew J1 plug with proper
plug. Tested both scope (using 222UTILS) and RTI-815 digital
outputs (using EXER), both seem to work.
At this point we don't know where our video server will live.
Littman promises a video board before he leaves town on Saturday
(Aug. 12 -- 2 days from now). We don't know what PC it will live
on.
8/15 Interpreter basically works. Transitions on analog outputs require
about 5 milliseconds.
8/17 Tested long "programs" containing digital outputs on my interpreter
yesterday. When you submit a commandstring consisting of very many
"DOT 0; DOT 1" commands, the time required for these commands gets
longer as the commandstring "executes." The interval for which the
low bit remains at 0 or 5 V begins at around 50 milliseconds, if
I recall correctly, and increases up to around 250 milliseconds.
Finally the VB program crashes with an "Out of string space" error
message.
This led me to develop an un-locker to remove the lockfile in cases
where the WEBRTI.EXE crashes before removing it at normal termination.
Today got an imagemap working. You see an 8-arrow'd Pan-n-Tilt
controller form. Click on e.g. the down arrow and you get back
an HTML doc saying "You hit DOWN." There's a bug in the R. Denny
docs on the subject: you must enter "imagemap.exe" in the URL
to which the ISMAP image is submitted, not just "imagemap" as the
documents say.
8/19 Met with Littman for a while, demo'd the CU-SeeMe camera controller
and WEBRTI program. He suggested that I add ability to read in
digital and analog values from RTI-815. I told him I can do this.
We went over stepper motors, he gave me a two-motor pan-and-tilt
apparatus and documentation on how to use a chip to step the motors.
He also showed me how to use an open-collector inverter to shield
the RTI-815 from the deadly 12 V logic involved with the motor
controllers.
Later in the evening I cleaned up the WEBRTI interpreter a lot.
Now it gives correct and nice diagnostic feedback, correctly
tracks "recursion" (i.e. "SOURCE" commands), etc..
Next order of business: Implement commands like "TEK," "LOOP,"
"DOTB," and input commands like "DINB," "DIN," "XAIN."
8/22 The fellow at CIT who co-ordinates the Fall Information Fair
is Jon Edwards, jedwards@phoenix. Maybe Littman and I can
demo there.
Late at night spent much time getting Tektronix scope to talk to
Visual basic. Crux of problem was proper settings of serial port
memory addresses and IRQ numbers. The final working settings are
therefore worth recording:
COM1 COM2
Address: 03F8 02F8
Baud rate: 2400 2400
Parity: N N
Data bits: 8 8
Stop bits: 1 1
IRQ: 4 3
It took an obscene amount of effort to get these settings right.
8/24 Spent a long time on the Tektronix routines. The behavior of
the routines is probabilistic. When I send button commands to
the scope to freeze the screen and stash waveforms CH1 and CH2
in RAM (with a view toward retrieving it shortly thereafter;
the idea is to freeze both waveforms at the same time), sometimes
things work correctly, other times the waveforms don't get stored.
Might have to slow the routine down way slow to make it work,
but early tests of this approach did not work well.
8/26 Thought of a great name for the project: SNIFFLE, the Simple
Network Interface to the Full Functionality of Lab Equipment.
(Thought of name "sniffle" days ago; it's the name of a friend's
Saab sedan; only later realized acronym fit.)
I think that as of today the functionality of the Visual Basic
program at the heart of SNIFFLE is complete and error-free.
Now I must test the system thoroughly, work out all bugs, and
document it.
Also on the to-do list: wire up the stepper motors and play
with pan-n-tilt implementation.
8/28 Called AIRPAX company, manufacturer of stepper motors, regarding
the motors we're using for pan-n-tilt stuff. They say our model
K82231 is obsolete, but they'll FAX me complete specs on it.
Last night I had trouble wiring up SAA 1027 controller chips because
I lacked info on which resistor values were appropriate to our
motors.
AIRPAX says their distributor is Sager Electronics, 800-724-37800
(yes, that phone number is correct -- just dial all of those digits
and all will be well). Sager, like AIRPAX, won't give out prices
on products until you're ready to buy. Weird.
9/5 Check to see if Visual Basic has an "eval" command. This would
let us send VB programs from client to server and let us replace
our toy macro language with a true programming language containing
powerful commands. I think I investigate this question months ago,
but Littman suggested the idea today and I said I'd check it out.
9/6 Got pan-n-tilt imagemap control panel to work. Must be careful with
GET-method URLs in .map file: if they're too long problems arise.
length limit seems ridiculously short. Probably due to fact that
URL args are *last* thing passed to cgi program on command line.
Cleaned up source code by shortening all lines to under 75 characters
(except for one very long line that Visual Basic won't let us break).
9/7 Littman found a CU-SeeMe reflector on campus: mongo.princeton.edu.
Littman says that X-terms can view the broadcast from our CU-SeeMe
server via MBONE something-or-other. We haven't gotten this to work
yet.
Upon investigation we discovered a product called "nv" which
supposedly displays CU-SeeMe on an X-terminal. It is installed in
/usr/princeton/bin/conferencing/, along with other related utilities
for internet teleconferencing (e.g. audio & whiteboards). The nv
man pages are not installed by CIT, so it's best to get them from
the source: ftp://parcftp.xerox.com/pub/net-research/nv*. I've
put the man page in my ~tpkelly/man/man1 directory, along with a
.ps paper on the subject of nv.
Littman reports a bug in session logs of SNIFFLE: Sometimes when
a barrage of commands is issued, or when two clients try to use
the server, bad things happen, e.g. wrong session log is returned.
I confirmed this problem when trying to demonstrate locking to
him. Dunno what's up until I stare at the code.
Fixed bug in session logs later at night. Now every time the
WEBRTI program executes a different log is generated. When too
many log files pile up in a special session log directory, the
client is warned about it and given an opportunity to delete
them with a single click.
9/14 Documentation complete. This log to be included in my project
report as an appendix.