response 25 of 60:

Jul 20 02:20 UTC 1995

I agree that Grex would want the two interfaces tied together
through Picospan, but there are technical difficulties that are 
in an area I'm not all that familiar with. Some kind of password
(arguable it could be a 1-time PW, rather than the account PW after the
first http transmission) would have to be shipped embedded in each http
request. The CGI script eould have to very the account password using shadow
logic (OK that I know how to do), and then setuid to the user and execute
picospan as a child with redirection.  How would this perform?
I see a lot of extra interpretation of .cfonce files, maybe we
can suppress that. 

Without account creation you don't have to deal with all the account
setup questions, shadow password system, and much more. Yes,
you still have to send passwords in the http though.

All I was saying is that it would be a lot easier to do if we didn't
have to remain tied to the picospan conferences.

response 27 of 60:

Jul 21 05:44 UTC 1995

I have thought of the possibiliity of implementing a Picospan-compatible
system. If we could determine all of the details (file formats, etc) of 
the Picospan internals, this is a possibility. The scripts could run as
cfadm, not root, as setuid() to individual users would not be needed,
since we wouldn't be trying to "fool" picospan with this approach.

Am I dreaming? Can we get at this information?

If we could, it could put an http face onto picospan without being
unbearable.

response 29 of 60:

Jul 22 05:00 UTC 1995

That's encouranging, John. I didn't even know that there was an internals
manual. I was worried about finding the controls for forgotten items,
scribbled responses, etc. I know the mnain-line stuff is pretty direct.
What do the conf. participation files look like?

One big problem with trying to combine a web front end and a picospan
(traditional) front end to the same data, is these participation files.
Somehow we'd have to make these files read/writable by both 
picospan (which uses the users perms for this file) and httpd(CGI script).
Since we don't want the CGI scripts to need to or to be able to call setuid(),
we need to give them r/w permission somehow. Perhaps r/w group permissions?
But then something would have to be responsible for doing chgrp on all
the participation files once, and continuously as new ones are created.

Yes I'd like to have them access under their regular Grex uid, but would
you prefer to have all would-be conferencers get accounts in order to use the
Web conference interface, or would you like it to be possible for them
to conference without doing so? I don't like the idea of requiring
accounts to use Web conferencing, but if we are to share the conferences
with picospan, it seems to me that we must.

response 31 of 60:

Jul 22 12:15 UTC 1995

Yup, those seem to be the datestamps for when the item was last read.
(Thanks Marcus for teaching us about Picospan's "date" command recently!
[In *Picospan*, you can type "date 0x300a9d25" to find out what date
the hexadecimal number 300a9d25 corresponds to.])

response 33 of 60:

Jul 22 12:29 UTC 1995

The participation files live in each user's home directory, hidden by a
leading dot "."    Summer agora is officially agora14, so in my home directory
(where I'm at when I log in) is (among many others) a file named
".agora14.cf", which contains in plain text Valerie's listing above.  You
could do a command like "!cat .agora14.cf" to get a listing, although it would
scroll right off your screen since there is a line for every item.  You can
also edit these files to change your conference name (the "change name"
command does this).

response 35 of 60:

Jul 22 20:28 UTC 1995

The major use of the 1st line is to determine if the file was somehow
damaged - if the line isn't there, then something is obviously wrong.  A
secondary use of the line is to include file format version information
- the 3 means this is the 3rd version of the file.  The format hasn't
changed in a long time, but if it were to change, this would allow
PicoSpan to figure out which format of file it was dealing with.

response 37 of 60:

Jul 23 05:24 UTC 1995

Good, it appears that accessing the various structures will be easy.
Now how can we arrange for these .cf files to be rw accessible to a
CGI script running under the httpd server. (Actually, it may be a script
or a program, but that's not the point.) We don't want the program
to run as root, so setuid(youruser) is right out. Without this feature,
a given user would have to have two sets a participation files, one
for http access and the other for picospan access. This will work, but
can't we and shouldn't we do better?

response 39 of 60:

Jul 29 17:09 UTC 1995

No one has responded here for about a week, but I have been thinking about
this a lot. Last week, I captured a short session of my own use of picospan,
mostly just reading coop and WIN. I converted these to a set of static web
pages. I spent some considerable time on this.

When I say static, what I mean is that they are in files. You can view them
with any web browser, (lynx, mosaic, netscape navigator, etc.) They show
one possible way that a web-based picospan session could look. I call this
new look "Webspan" and take credit for it, but I am showing it to all of you
so that you can criticize it and give me feedback. I plan to make it available
to Grex for free if Grex is interested.

In a *real* web-based conference system, these would not be web pages stored
in files, but would be produced on-the-fly by the WebSpan conference system.
This is only a facsimile of that. Let me know what you think.

Try it with NN 1.1 if you can -- it looks much different.

It is full of missing links. If something doesn't work, it's just because 
I didn't write that part -- try another one.  It has errors. It starts you
assuming you are an anonymous browser, but then it winds up with posting 
turned on. Do not be concerned about this. The purpose of these pages is
to show you about what it would look like, not to simulate a full session.

Grex will need to turn on CGI scripting in httpd in order to support a
real version of a system like this.

I don't think the bandwidth is much higher than with a picospan user, but
it is slightly higher. I do expect that if this were implemented
it would be compatible with picospan, and share conferences. That means
that in the implementation, the CGI code will have to be able to setuid(cfadm)
and it will have to use the exact locking mechanism used by picospan.

I am pointing to janc's newuser form, as it is an integral part of this plan.

To view, look at
http://www.cyberspace.org/~srw/www/webspan/welcome.html

Non members can run 
lynx ~srw/www/webspan/welcome.html
directly on Grex. 

response 41 of 60:

Jul 31 06:10 UTC 1995

ack. I gave the wrong url. Sorry. The httpd daemon puts in the www, so
you shouldn't have it in the url. Here is the real URL:
 http://www.cyberspace.org/~srw/webspan/welcome.html
Please *do* look at it in Netscape Navigator.
sorry for the mixup.

response 43 of 60:

Aug 1 00:19 UTC 1995

I got to sfgate.com and was *partly* impressed.  Nice that they are
using YAPP software.  And they do maintain a history of each user's
participation.
        The big drawback is that sfgate.com is *glacially S-L-O-W.*
I almost fell asleep waiting for the "host contacted, waiting for
reply" message to result in something happening.  I guess they must
be popular.  But such slowness takes a lot of the spontaneity out
of conferencing.

response 45 of 60:

Aug 13 02:11 UTC 1995

I've been exploring around in the conference area on the disk, /bbs.
I haven't looked for much there before, but now that I've been thinking
about how to implement this, I have more questions.

conflist looks pretty straightforward to me. It provides a list of
names that the conferences have. I am curious to know if there is an
on-line description of each conference somewhere. 

If you type "help conf" where does that text come from?

Here's another question. Each conference has a data file named "sum"
in its directory. Does anyone know the function and/or format of this?
I imagine it might be in that internals document, if it can be found.

response 47 of 60:

Aug 13 05:04 UTC 1995

Ah. /bbs/public.txt, Thanks. It has been a while since I looked that over.
The problem I have is that a system like this would need the info
that is in that file in a more structured form so that it could
compute an html page with hyperlinks to each conference.

Since the info is only in a text form, I would have to consider the
possibility of modifying it for use in a CGI conference application.
The disadvantage would be substantial, because I don't want to
burden the cfadms with having to maintain two copies of the public.txt
descriptions. 

I will have to ponder this more. Others are welcome to chime in 
with brilliant solutions.

One thing that public.txt does that I see nowhere else is that 
it groups the conferences into categories. I like that.

response 49 of 60:

Aug 13 11:40 UTC 1995

Wouldn't there be some problems with authenticating a person that is
making a post from a cgi script?  What if we used something like
Netscapes shttp (secure http)?  That way, someone would have to enter
their account and password at the web client (netscape), and then
netscape itself will keep track of the user.

This would seem more resonable then letting people post things
anonymously...