
The thing to remember about this directory, which was a subdir of my
own home web tree, is that it could be seen from the perspective of
e.g. my host, as /usr/local/www/de/whatever, or from the perspective
of the apache server as ~de/whatever, or from the perspective of
a user on the apache server host as /lopt/apache/u/de/whatever.

It makes a difference.

I originally called this dir Tcl2K, to match the cgi-bin/Tcl2K
on the other side of the server.  However, I had to change the
names when I made these tarballs, so it's now called Process.
Don't let this confuse you.  References to ~de/Tcl2K in 
common.tcl on the cgi side are referring to this dir.

The GDBM database is living over in cgi-bin tree on the apache
server host (you did read the README in the other tarball first,
right?).  You can't see it from my host.  So any script that
does tclgdbm operations has to run on the http server host.

total 98
-rw-r-----   1 de       lickstaf    47847 Jul 19  1999 ref.txt

ref.txt is a CGItcl reference manual in plain ascii text.

-rw-r--r--   1 de       lickstaf      560 Jul 22  1999 template.html
-rw-r--r--   1 de       lickstaf      275 Jul 16  1999 test.html
-rw-r--r--   1 de       lickstaf      202 Jul 16  1999 test2.html

these are just some test html files and a template for making
finished (HTMLified) reviews for later viewing (this is
done automatically at review ingestion time).

These directories are for processing incoming reviews that
arrived via SMTP (mail).  from the processReview.tcl script:

	set spooldir /lopt/apache/u/de/Tcl2K/rcv
	set copydir /lopt/apache/u/de/Tcl2K/pro
	set logdir /lopt/apache/u/de/Tcl2K/log

Notice those path names.  This script runs on the http server
host.

This is how it works:  someone mails in a review form.  Through
mail aliases it gets thrown at the tclPapers-mail.tcl script.
This script puts the file in the incoming directory, as
Incoming.<toyclock value>.  When the file is all received and
complete, it gets moved to the spool dir rcv.

Later on, processReview, running as a cron job on the http
server host, will come along and grab whatever is in the
spool dir rcv.  Note the 2-dir mechanism protects it from
trying to grab an incomplete file in the act of being
received.

drwxrwxrwx   2 de       lickstaf      512 Oct  7 00:13 incoming/
drwxrwxrwx   2 de       lickstaf      512 Oct  7 00:40 rcv/

The processReview script will get a list of all files in rcv at
the time it woke up, and it will start processing them.  It logs
its activities in the log dir.  If it is successful in processing
the incoming form, it moves that file into pro (processed).  If
it fails for any reason, the file goes into bad (problems) --
I think I moved them manually into "bad" because I don't find
a reference to it in the scripts -- we'll leave that as an
exercise for the reader :-)

If you look in "bad" you will see a couple of mail messages
that someone accidentally sent to the review-eating mail
address instead of to me.  They were rejected and flung
into this garbage bin, which I would check every morning.

Some mechanism in the DoReview.cgi script autogenerates an 
acknowledgement after ingestion of the review, which is 
automagically emailed back to the reviewer.  These acks are 
also archived in the ack dir.

drwxrwxr-x   2 de       lickstaf     1024 Oct  4 01:28 pro/
drwxr-xr-x   2 de       lickstaf     1536 Oct  7 00:40 ack/
drwxr-xr-x   2 de       lickstaf      512 Oct  2 23:05 bad/
drwxr-xr-x   2 de       lickstaf     1024 Oct  6 21:45 log/

In each of these dirs I have left a README showing what an ls -l
looked like during full-on operation of the system.  You should
probably delete these READMEs from your installed version!
I left a sample log file in the log dir as well.

drwxr-xr-x   2 de       lickstaf      512 Jul 19  1999 images/

another copy of "images", and probably the one that is really
used (check common.tcl)

These next two dirs are where the real information (the papers
and the reviews) are stored.

drwxrwxrwx   5 de       lickstaf     4096 Oct  7 00:13 reviews/
drwxrwxrwx  35 de       lickstaf     1024 Sep 14 13:13 submissions/

In the submissions directory are a number of subdirectories,
each one containing various files submitted by an author,
like PS, PDF, HTML, plaintext, a cover letter, etc.  These
directories have names like submit26.  This is where the
submissions form puts the files specified by the admin.

Note that the review files (see the README in reviews dir) are 
also anonymously named, names like review113.html.  The mapping of
review number to author/paper/reviewer is done in gdb of course.
The review processing code generates these HTML versions of the
reviews for easy online reading via the main cgi pages.  We
can all read each others' reviews.  The review*.html files are
made from the template.html file.

-rwxr-xr-x   1 de       lickstaf    10217 Oct  4 00:34 processReview.tcl*
-rwxr-xr-x   1 de       lickstaf     1971 Jul 30  1999 tclPapers-mail.tcl*

two very important scripts!  The tclPapers-mail.tcl script is
the one into which incoming review forms are directed via sendmail.
It plonks them into rcv directory via incoming directory.

The processReview script comes along later and ingests the review form
into gdb.  Read these scripts!


-rwxr-xr-x   1 de       lickstaf      678 Oct 12 17:41 getpapers*

This is another little example script showing how to get into
the gdb data.

-rwxr-xr-x   1 de       lickstaf     3956 Oct 13 11:02 mkhints*
drwxr-xr-x   2 de       lickstaf     1024 Oct 12 17:38 hints/

And lastly, this is the script I used to generate a nice polite
letter to accepted authors, gathering up all the reviewers' comments
(anonymized) and mailing them out.  My favourite trick for mass
mailings of this kind is to create a subdirectory and in it
create a file per recipient with the name of the file being
the recip's email address.  Email addresses are almost always
valid unix filenames.

Then it's a piece o' cake to nip down into that dir and do this
(csh)

foreach r (*)
Mail -s Paper_Accepted $r < $r
end

OK, that's about as much tour guide as you will get for this code.
I got it with no READMEs at all :-) and managed to make it work,
so you should, with a little perseverance, be able to to likewise.


