[Oberon] BlueBottle: rebuild CD image; POST

[mcintosh at vima.austin.tx.us]

rebuild CD image
----
The file Aos.Tool is a script that facilitates the process of
building an AOS filesystem image on a file that can be burned into a
bootable CD.

There are a small number of problems using it in the field.  The
source modules that are named in the Private group are not in the
distribution.

The .Mod extension of those modules can be replaced with the .Obx
extension, and a correct Distribution tool does "compile."  They must
also be commented out of the Private group.

In my production of a "custom CD" I did include files with the name
Release.<base name> for the files that have that name in the Aos.Tool
list.  I added some extra commands to Aos.Tool so that I could add
those few files to the .zip files.  My thinking on this is that the
Release CD should be idempotent under the build / install operators,
and this change makes it closer to idempotent.

I was also reluctant to rebuild the system on top of my working AOS
partition.  Fighting with that paradigm probably caused more
misadventures than I was trying to avoid, however.

There was some suprise also in working with ZipTools, after using
OFSTools.SetDefault.  The file shadowing did something that suprised
me, though I didn't take good notes and have forgotten what it was. 
It wasn't misbehavior of the software, just another detail to be
careful of when new users are working with new software.  I was
pleased to learn that WinZip reads the same format files that
BlueBottle produces.  Somehow I had thought years ago that the Oberon
zip files were a custom format.  However, windows doesn't know what
to do with the <partition> ":" <path> format when the partition has
more than a single letter.  

I like the format of my TarDump program slightly better than the
current ZipTool format in that I could just edit the name before
extracting the file, and the name (or entire path) could be changed. 
I did not find how to change a file name on extraction in the WinZip
program, nor in the ZipTools program.


POST
----
The experimental POST plugin for the web server is not in the
distribution, and it is commented out of the Aos.Tool list of files. 
I really want POST for a project that I am working on, so I have
worked on my own version.

I have placed a directory http://cda.mrs.umn.edu/~mcintosa/BlueBottle
and there are a couple of zip files in this directory related to the
POST plugin.

These files contain an initial static design for some web pages that
will become server side modified pages, and return data from a
database + calculations back to students.  I am able to place these
pages in the relevant directory
        FAT:/httproot/peer
and I can read the pages from Netscape or Internet Explorer.  The
current POST plugin reads the HTTP headers and builds a debug web
page that just echoes back header information.  So much of the method
extensions do work correctly.

The problem that I am stuck on right now is that occasionally, when I
submit from the page for the file upload, the Bluebottle server does
not seem to get as many bytes as Netscape says that it is sending. 
I'm not sure that I see evidence that the output is chunked, but I
assume that it is supposed to be.  So this is clearly a trouble area
in my sample code.

----
I put a fair amount of effort into making a Coco grammar for the RFC
for a URI, only to realize later that this only applies to "GET"
methods and not to "POST" methods.  If one really obscure production
is removed, the grammar is pretty well behaved.  I'll try to remember
to put a .zip file for this onto the web later.