Re: Proposal: WIT over USENET or Mail (Nick Arnett)
Date: Thu, 9 Jun 1994 20:55:20 +0200
Message-id: <>
Precedence: bulk
From: (Nick Arnett)
To: Multiple recipients of list <>
Subject: Re: Proposal: WIT over USENET or Mail
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset="us-ascii"
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Mime-Version: 1.0
At  8:12 PM 6/9/94 +0200, Daniel W. Connolly wrote:

>For the purpose of the HTML 2.0 review, I suggest we use the www-html
>list and a hypermail archive (I got wind that one is in the works).

As mentioned here earlier today, there's mine at:

<a href="">WWW-talk</a>

.. which does more formatting and somewhat different style of threading
than HyperMail.

and HyperMail at:

.. which does a better job (for now) of providing date ranges, such as
"recent" messages.

>Alternatively, if somebody wants to set up a special list just
>for the HTML 2.0 discussion (with a hypermail archive, of course)
>I'd be happy to use that in stead.

I don't have listserv abilities, but I'd be happy to do the archive.

>I would like to be able to create WIT-style views of the archive of
>this discussion, so we should adopt some convention for expressing the
>topic/proposal/argument structure in RFC822 headers. See below for

WIT is taking a stab at representation of dissent, which is a key to
collaborative processes, but it only starts to accomplish that.  Some sort
of collaborative filtering and archiving is important, too.

Unfortunately, I'm working in a Mac environment because I'm prototyping
with HyperCard.   I'm afraid that leaves me somewhat out of the mainstream,
though.  However, I just nabbed a copy of the Mac flavor of Perl, so
perhaps I can pretend to be in the Unix loop, after all.

>Why not just use WIT over HTTP? WIT over HTTP has no privisions for
>scalability. Even under the current load, it is unresponsive and
>Here are the features I think we need, and how they map to
>the HTTP, internet-mail, and USENET mechanisms:

[specifics omitted]

Unfortunately, statelessness immediately becomes an issue as soon as you
introduce the concepts of subscribing and new messages on the server side.
There are a lot of reasons not to do so... but I don't want to rekindle
that discussion.  I'll just suggest that if we want to have something
working *soon* those states need to be saved at the client.  That's the
Usenet model, too.

I'm trying to accomplish most everything you describe, but without making
any changes to the server.  Clients could make it easier by providing
people a means to save the states, though.  I suspect that whatever I
create will require the user to remember to save his or her last page.

In any event, I'm very happy to participate in this sort of endeavor.  I
intend to broaden it beyond narrative information (news, mail lists, etc.)
to archival and faceted information retrieval.

You'll see that on one of my menu pages:

There's a placeholder for "Nick's Picks," which is where I'll be
maintaining a list of my favorite recent messages.  I'd like to enable a
few other people to do the same, remotely, especially people with a strong
point of view that's different from mine.


Multimedia Computing Corp.
Campbell, California
"We are surrounded by insurmountable opportunity." -- Pogo