response 1 of 15:

Jun 11 20:41 UTC 1995

   A Neat Idea, Jan.  I thnk its a great thing to do.  I know that the
CGI stuff needs to be worked on, but this is another reason to do it.

response 3 of 15:

Jun 11 21:57 UTC 1995

(Oops, almost forgot, I love the idea and would offer to help if I'd
had a chance to learn CGI, but since we don't have it here, I haven't.
Yet.)

response 5 of 15:

Jun 12 00:47 UTC 1995

If I work on this, I would need
  (soon):
    - a copy of Grex newuser source.  I'd want to use as much of the same
      code as the regular newuser program as possible.  Namely a lot.
  (before long):
    - CGI installed on Grex.  Robh says it isn't, but it is standard NCSA
      stuff and should be be straight-forward to install.  Still, it would
      presumably take a root to do it.
    - access to the cgi-bin directory.  All CGI programs normally have to
      be installed in cgi-bin, which users normally can't access, for very
      good security reasons.  I'd need to be able to install stuff there to
      test it.
    - a friendly root.  Once it is debugged, the thing is going to have to be
      suid-root to actually work.  (All the really critical code will be
      lifted unchanged from newuser, so there should be little risk).
    - a friendly webmaster.  Once it works, the Grex web Page needs to point
      to it.

I've reviewed what the NCSA documentation has to say about CGI security,
and I see no problems there.  To quote their manual, "This is not rocket
science."

response 7 of 15:

Jun 12 17:32 UTC 1995

First I agree that with the current state of the art on CGI, you *can not*
let users write scripts.  However, if written with a modicum of care, staff
installed scripts are perfectly safe.

Why this is desirable:  I see it first and foremost as simply a friendlier
and simpler newuser interface.  For anyone familiar with the web, it is
much simpler to fill out a standard web form then to run an unfamiliar
program like newuser.  For example, they can edit their answers easily using
the usual methods their browser support.  I think Grex needs to do everything
they can to make the system as approachable as possible by as many people
as possible.  It's not that newuser has a bad interface, but as more and more
people travel the web, it is more and more the the standard interface that
people understand.  so if we can make that critical first step into Grex
more familiar to an important segment of our users, it is worth doing.

Also, a lot of the talk about "What is an interupt character" that appears
in the current newuser can be pulled up with a "click here for more
information about interupt characters."  Thus, not every newuser has to sit
through pages of text explaining things they already know.  They can very
easily ask for what they need.  As anyone who has worked on newuser knows,
one has to make hard choices about how much you tell the user.  Too little
talk, and he is confused and likely to give up.  Too much talk, and you are
likely to overwhelm him with information he already knows or doesn't care
about.  The hypertext interface of the Web allows us to break out of that
bind.  If we design the page well, the user can ask for as much information
as he need or wants, can skim or read as he likes, and can process it in any
order he likes.

Second, I see it as a sensible first step in a direction that I think is
important to Grex's long range growth.  As STeve has said elsewhere, the
Web, or its decendents, is the future of the Internet.  If Grex is going to
stay on the leading edge of our business, we must dive into the Web.  To
do this, we must start making more of our services available over the Web.

I'd eventually like to see a Web interface to PicoSpan.  To do something
that would let people have read-only access to items would be simple enough.
But to do a really nice Web-PicoSpan we need to be able to identify the
person so we can attach a name to his responses, and maintain .cf files
for him.  I understand some web servers support user authentication so that
a person has to sign on and give a password to access some functions.  I
haven't investigated this enough to know how good it is right now, but it
is obviously a capability that is going to become available on the web, if
it isn't there already.  Once we have that, we can have a person log on by
giving login and password on a web page, then enter PicoSpan, with input and
output filtered through CGI.  Doing this well would probably be pretty hard,
but the result would probably be the best conferencing system on the net.
Combining the power and logical structuring of PicoSpan with a standard
point and click interface, while retaining the full regular interface for
power users, would blow away anything else I've seen on the net.  This
isn't going to happen soon, and I'm probably not going to build it, but
being able to create accounts on the Web is a good first step to being able
to use them.

Finally, hey, it's a cool thing.  How many web pages are there on the net
where you can fill out a form and instantly have an account on a Unix system?
I promise, a stunner like that is going to make a lot of hot-lists around
the Web, and attract a lot of new users.

response 9 of 15:

Jun 13 01:04 UTC 1995

Hey, you gotta start somewhere.  We can't say "Gee, we better not improve
this part of the system, because it will be too much better than the rest of
the system."

And in any case, this is not a hard thing to program.  I doubt if it will take
me as long as 8 hours to put together a solid version.  There's likely going
to be a lot more time fiddling with the text and formatting of the page
itself, but that doesn't take any genius.  Just about any computer literate
person can figure out how to do that part.  It doesn't place any big demand
on any Grex resource.

response 11 of 15:

Jun 13 07:40 UTC 1995

Go for it.

response 13 of 15:

Jun 18 14:35 UTC 1995

ObPeeve:  Never say "click here" in HTML.

This seems like a reasonable idea, and for people familiar with Web stuff
(a lot of them) the interface is easier to use.  I'd encourage you to
use a method of POST in the real implementation for security and sanity
reasons.

response 15 of 15:

Jun 19 02:48 UTC 1995

(I agree that "click here" suxs, but in describing what it would be like off
the web it is a clear way of stating it.)