Re: Re WIT
Brian Behlendorf <brian@wired.com>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 14 Jun 1994 03:28:02 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <Pine.3.89.9406131801.w3943-0100000@tired.wired.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: brian@wired.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Brian Behlendorf <brian@wired.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Re WIT
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
On Tue, 14 Jun 1994, Michael A. Dolan wrote:
> At 09:32 PM 6/13/94 +0200, Dan Hinckley wrote:
>
> >Does anyone think it a good idea to come up with a requirements
> >document/RFC?
>
> Yes.
It'd be a big challange to write and keep as flexible as I see it
being...
> >Here goes .. In my voluminous spare time IF no one else is
> >already working on such a project, I will volunteer to compile a list of
> >requirements, so our implementation ideas can be considered in context.
>
> Here's a few (probably not so easy) ones:
>
> 1. Offline composition - unless I missed something, it appears
> that one must be connected semi-live to the various WIT forms
> in order to have a meaningful session. Of course one could
> cut and paste, but...
Well, in the Web (tm) there's really no difference between online and
offline composition - when you download a form and fill it out you're not
still connected to the machine from whence it came, so it doesn't matter
of you take 5 minutes or 5 days to fill it out. Of course, I'm probably
being pedantic here, and you are referring to using a different kind
of editor for writing the message, in which case I agree it might be
good but that's something that needs to be addressed on the application
level (i.e., how to get one application to dump data to another's input
area).
> 2. Some sort of heirarchical organization - this seems designed
> in, but it might require some human intervention to keep it
> rational.
If it's easy to allow users to collapse trees and move certain posts back
to a top level when the discussion has progressed significantly from the
original topic, then that would be great for most purposes...
> 3. An email interface - no matter how its designed there will be
> those that can't/won't/don't use it for various reasons. Maybe
> a script could be written to handle inbound email, HTML-ize it,
> and stuff it into the right place ? This might also solve other
> silly requirements such as (1) above.
I've been debating this in my head many times - if someone doesn't have the
capability to view something on W3, why are they participating in a
discussion about improving it? I really do not want to come about like a
snob, but it seems analogous to wanting a snail-mail interface to e-mail
mailing lists 10 years ago. At some point you have to define a lowest
common denominator, and the lower that is the more limited your choices
are.
Having said that, I also think it might not be too hard to add. Presumably
every message posted will have some sort of message-id. WIT makes the ID be a
mirror of its structural location, which is Yet Another thing to improve.
Anyways, it's not hard to forward all new posts in a given topic to a given
list, and IF the headers are written right and the mail software knows how to
handle them, it could work for the most part seamlessly. However, I'm not
optimistic about this second part. Eudora is horrible in responding to the
Reply-To: field correctly. Pine and Elm seem to handle it fine, but they
are rapidly becoming superceded by PC and Mac-based mailers which have
their own ideas on what RFC822 really means. So, receiving mail from a
WIT-like entity isn't too hard, but replying back to it will never be
as reliable as we'd want.
Brian