Received: by taz.hyperreal.com (8.6.12/8.6.5) id PAA17387; Fri, 21 Jun 1996 15:43:18 -0700 Received: from life.ai.mit.edu by taz.hyperreal.com (8.6.12/8.6.5) with SMTP id PAA17378; Fri, 21 Jun 1996 15:43:14 -0700 Received: from volterra.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for new-httpd@hyperreal.com id AA01569; Fri, 21 Jun 96 18:43:14 EDT From: rst@ai.mit.edu (Robert S. Thau) Received: by volterra.ai.mit.edu (8.6.12/AI-4.10) id SAA29406; Fri, 21 Jun 1996 18:43:13 -0400 Date: Fri, 21 Jun 1996 18:43:13 -0400 Message-Id: <199606212243.SAA29406@volterra.ai.mit.edu> To: new-httpd@hyperreal.com Subject: Authoring support? Sender: owner-new-httpd@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com If you've got Netscape Gold or GNN press lying around, it might be fun to try saving files to http://www.ai.mit.edu:8000/xperimental/sandbox I've tried it with both, and data from both seems to show up, but your milage may vary. It should let you in without authentication (there's a No_auth line in a control file which allows this). NB this is an experiment --- the server itself and the directory may both vanish at any time. If you've got neither package, and you're really curious, I recommend trying GNN Press first --- http://www.gnnhost.com/publish/upgrade/gnnpress.htm GNN Press seems to be somewhat less flaky than at least the Linux beta of Netscape Gold, which has a really annoying tendancy to hang on PUTs if a prior PUT got any kind of an error. Unfortunately, at least on my screen, GNN Press's default fonts are way too small for comfort, but that can be fixed, though it's a bit of a hassle. (It also has a tendancy to put up bogus "You may not be able to save a document from this protected area" dialog boxes when you start to edit a document that you fetched from the sandbox --- ignore them). I'd like to recommend the W3C's authoring tool, Amaya, but it seems they haven't released it yet. Pity, that. FWIW, the sandbox directory is back-ended by RCS, and uses the CGI environment variables on each PUT for log entries (or tries to --- I don't exactly trust it yet). If you're brave enough to try saving an image file, that should (there's that word again) get uuencoded before being fed to RCS, so RCS doesn't choke. (The engine here is a PUT back-end CGI script, which doesn't rely much for support on the web server itself, except for a little paranoia support which I tossed in along the lines I've been discussing, to make it at least more difficult for randoms with CGI privilege on the web server from faking up PUT requests into other peoples' directories). Hopefully, this code will be in distributable shape in the not too distant future... rst