On Fri, 9 Jul 1993 12:57:38 +0300 Matti Aarnio said:
>>From: "F. Scott Ophof" <Ophof@CS.UWindsor.Ca>
>> And I'd sincerely hope
>> Eric wouldn't grumble at <listserv@..>-type addresses being used.
> No, he won't, however he does expect that such LISTSERVers do act
>like Revised LISTSERVs, and one BIG snafu in it is R-LISTSERV's
>DISTRIBUTE-protocol, which is documented in RFC 1429. (Yes, it really
>looks alike MVS JCL, so what ?)
>Actually it is a sort of SMTP inside the mail body. R-LISTSERVs just
>handle it better.
Yes, but that's not much of a recommendation... (grin) I don't want
to flame, but imho it's also time a better Mail Transport Protocol
were developed than SMTP. Heck, maybe X.400 *is* the way to go?
Forget about the ridiculous user-addressing syntax; it clearly never
was meant to be human-readable, nor will it ever be. Besides, the
same can be said for the DNS format. An interface between machine-
readable addrs and something we humans can read is needed anyway.
But that's fodder for another list/group.
> The protocol is easy to implement, but how do you find the (near-)
>optimal list of peers willing to run it ? R-LISTSERVs do it by
>centralized control, and monthly distributed routing database.
>(They are run in the BITNET after all..)
Get together with the relevant BITnet people? They are probably
wrestling with the same problem for when "Revised LISTSERV" comes
to the Internet.
Your idea of getting together in Amsterdam sounds great! Wish I
could be there, listening to great minds at work. (sigh)
>Hmm.. Consider scenario:
Yikes! Out of my league. *Gone*! :-)
>> If I'm not mistaken, Tasos' intention was that "ListServer" be
>> indistinguishable from "Revised LISTSERV" as to the common subset
>> of functionality and user-interface.
> Well, let commands be the same, and their behaviour, but it can
>still present a bit different outlook ;)
Erm.. Please not if it confuses the users. And please note that it
certainly is time we all started thinking of users possibly having
differing mindsets. IMHO we should go one of the following routes:
1: Make the current user-interface FULLY understandable by ANY
human, be heesh a computer-user or not.
2: Ensure that the current interface is purely consistent for
machine-readability, and implement a user-interface ON TOP of
it, this last interface to be installed on the user side (a la
client-server model), completely adapted to the user and the
machine it's running on.
If we do (1), then we can be sure to run into trouble; there is NO
way a command set can be devised that is useable by ALL people on
Earth with the SAME ease-of-understanding. And I really don't think
it's fair to force English on non-English speakers.
This leaves route (2), which opens up the possibility of tailoring
that interface to each INDIVIDUAL users' wishes/mindset.
My point here is simply to indicate that we ARE at this milestone,
and it's nearing decision-time...
Regards.
$$\
|
|
