Newsgroups: bit.listserv.lstsrv-l
Date:         Sat, 21 Nov 1992 02:32:23 +0100
From:         Eric Thomas <ERIC@SEARN.BITNET>
Subject:      Re: Large list processing - battle of the LISTSERVs
              20 Nov 1992 20:20:24 EST from "Forum on LISTSERV release 1.7"
              <LSTSRV-L@SEARN>

On  Fri, 20  Nov 1992  20:20:24 EST  Alexander Dupuy  - CS  type militant
<dupuy@CS.COLUMBIA.EDU> said:

>Well, I'm not  an expert on BITNET,  but I thought that  there were only
>two public  INTERBIT gateways  on BITNET  (you said  there were  more on
>EARN).

It is  more complicated, there  are a dozen such  gateways in the  US but
only  2 have  been  registered  in the  topology  database for  politico-
operational  reasons  (which  fortunately  are being  worked  on).  While
LISTSERV only sees 2, all 12 do get to handle LISTSERV traffic; it's just
that LISTSERV  may forward mail to  a remote gateway when  the local host
runs  one because  it  isn't declared  in the  topology  database. The  2
registered ones do get a lot more  traffic than the others, but they have
such  a  big  capacity  that   8500  extra  subscribers  don't  make  any
difference. My initial  concern was that this might fall  into one of the
smaller INTERBIT's.

In fact  we then learnt that  UBVM uses a modified  configuration file to
direct these distributions to a local SMTP/MAILER, so the load is on UB's
computers and lines.

>But you  yourself pointed out  that BITNET  LISTSERV's idea of  the best
>peer for  Internet subscribers was likely  to be an EARN  site (not very
>optimal for lists with mostly U.S. Internet subscribers),

So don't put peers in Europe,  or then tell LISTSERV not to automatically
forward subscriptions there until the US INTERBIT gang have got their act
together. How would the unix list server spread the load anyway?

>Probably because  most Internet subscribers  don't know very  much about
>mail-based server technology.

And perhaps because they are happy with what they are using now?

>Un*x L*STSERV  is relatively recent,  and the interactive  features have
>only become available in the latest release.

Well I've seen unix people explain the complete lack of usefulness of the
TELL interface to  the VM LISTSERV hundreds of times  (the argument being
that mail is  just a few seconds slower and  doesn't take more keystrokes
if you have an alias for your main LISTSERV). I personally find TELL very
useful, but I wouldn't ask a list  owner to increase his workload just so
I could use TELL the 5-10 times a year I send a command to his server.

>And   given  the   different  natures   of  the   BITNET  and   Internet
>architectures,  I think  it is  pointless to  try and  find one  peering
>interface which works for both of them.

Well I  beg to disagree. The  protocols LISTSERV are using  work with the
Internet with the  addition of one new primitive. At  the moment LISTSERV
still requires an NJE link, but this  is only due to (a) the present lack
of  a mechanism  to register  non-NJE  servers in  the various  databases
without breaking older servers which do  not have the code to handle them
and (b) a half dozen routines,  independent of the protocols, which still
assume NJE addresses. Both items are going to be addressed, it just isn't
a high  priority item  at the  moment. FINALLY getting  a mailer  able to
handle lines longer than 80 and  supporting it was much more important to
me.

>Since most users don't ever see  the peering interface, I don't see this
>as a problem.

If you assume  the BITNET and Internet servers shouldn't  be able to peer
with each other, you are right.

>Which  is  what is  happening,  especially  with other  Unix  mail-based
>subscription managers.  I find it ironic  that Tasos and I  are the ones
>arguing  for  as  much subscriber-interface  compatibility  as  possible
>between the BITNET  and Internet worlds, while you and  most of the rest
>of the Internet list-managers seem  content to ignore each other's work,
>rather than trying  to create a more powerful synthesis  of the two (and
>no, this  doesn't mean I  want to force  everybody's mail servers  to be
>running the same implementation).

First,  let me  point out  that by  no means  do Tasos  and you  have the
exclusivity of worrying about syntax compatibility. I find this statement
and the use of the word 'two'  when referring to BITNET and Internet list
managers a bit presumptuous, and will refer you to the 1.7e release notes
for the  name of a  competing product  whose authors are  concerned about
this sort  of things and  which, in my  personal opinion, is  superior to
what you are using.

Second, I really  don't understand what I am accused  of not having done.
Joe decides that it  is Bad to only have evil  IBM stone-age list servers
with  brain-damaged syntaxes  and makes  a 200-liner  in perl  which uses
'add' rather than  'subscribe' and 'scan' for 'review'  or whatever. What
*am* I supposed  to do about it?  Waste time telling Joe it  is uncool to
have  incompatible  syntax  when  I saw  his  announcement  saying  "more
sensible command set",  and be called a fascist for  attempting to impose
my syntax on him? Change LISTSERV to do like Joe? Let's be real! Granted,
the present situation is that there  are only a handful of "leading" unix
list  servers with  a  non-negligible  user base,  but  this whole  thing
started as a sudden surge of 200-liners here and there, each of them with
different and incompatible syntaxes. What was  I supposed to do, whine? I
suppose that is not relevant and we should look forward. Fine, so we have
a  handful of  leading unix  servers which  we should  worry about  and a
couple score 200-liners  which we can ignore. The  handful have different
and incompatible  syntaxes and a large  enough user base to  make changes
difficult, and I respect that. Now, my  user base is probably an order of
magnitude larger than  the cumulated user bases of all  the unix servers,
so who should change his syntax? I have made upwards-compatible changes I
felt I could make  to help the end users. I am  open to more suggestions.
But I  simply can't make  incompatible changes, and  this is not  open to
discussion.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU