Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!psuvax1!psuvm!IVORY!MWH
From: mwh@IVORY.EDUCOM.EDU (Michael Hrybyk)
Newsgroups: bit.listserv.policy-l
Subject: Re: User interface for list postings
Message-ID: <POLICY-L%90020518241398@BITNIC.BITNET>
Date: 5 Feb 90 23:24:34 GMT
Sender: Discussion about BITNET policies <POLICY-L@BITNIC>
Reply-To: Discussion about BITNET policies <POLICY-L@BITNIC>
Lines: 79
Approved: NETNEWS@PSUVM Gateway
Full-Name: Michael Hrybyk
Comments: To: POLICY-L%BITNIC@pucc.PRINCETON.EDU

>Development of MAILER and MAIL/MAILBOOK (supported by Richard Schafer
>at Rice) have both been cooperative efforts of the users of the
>software with a site willing to provide a development center.  My
>personnal feeling is that the whole topic of portable (system
>independent) code has been used as a smoke screen by some parts of the
>network to not create similar environments for their platforms.  I
>believe that suggesting that software should be developed by BITNIC
>amounts to the same thing.  Why didn't a similar environment develop
>for the UREP/JNET machines (to pick 1 group)?  Where were the sites
>willing to develop software (at their own expense) to be compatible
>with the systems already on BITNET?  Why did no support groups develop
>for those development projects that did occur?  (If they existed, they
>sure were awful quiet.)  What was different about the VM systems from
>the rest of the network?
>

I think mta/ua development is a bad example, as there exists mmdf/sendmail
and pmdf, largely the result of volunteer development effort. It just
so happens that these mta's service all types of protocols, not just
nje/note/bsmtp, and therefore can't make the claim to be 'BITNET' software.
pmdf/mmdf, eg, has bsmtp, phonenet, uucp, smtp, and x400 (I've left
out a few) channels, and was largely done by folks at UDel, BRL, BBN,
Harvey Mudd Coll. and Univ. Ky. (sorry if I've not given full credit
to all due here). Sendmail likewise has multiple delivery modes, with
PSU support for BSMTP.

However, there is a lack of effort in getting LISTSERV, NETSERV, and
EARN tools available on non-VM platforms. In part, it is hard to fit
LISTSERV into a general facility on VMS or UNIX; it would have to be
done from scratch. Since the bulk of LISTSERV is in assembler and REXX,
the developer would have to start from the command language and engineer
backwards to the system. It would have been nice to have the central
routines written in a more portable manner, but this is no excuse
for lack of development.

For non-IBM systems, just getting the NJE emulation software off the ground
and working took some real effort. On IBM systems, the transport
layer is a given, no extra products or hacking required. The extra time
spent in maintenance mode on non-IBM systems tends to sap energy fast.

Portability is not a smoke screen; it makes life a lot easier. But
arguing that BITNIC (or some central agency) take on the role of
primary software developer in order to get similar services across
hardware and OS's just may be blowing a few puffs.

>If you can answer these questions I think you will be a lot further
>along the route of being able to decide what would be a good approach
>for software development on BITNET.  I know I don't have any answers
>to them.
>
>Does anyone?
>

John, you are on the mark here. The general questions are

1. what services should CREN/BITNET provide to its community of users?
2. how should software be developed, maintained, and distributed in order
   to fulfill the service requirements?

My answers (and this does not reflect an official position) in short:

1. coordinated mail delivery systems; robust file and information servers;
   discussion list, news, and bboard facilities; network hook-up assistance.

   Sound familiar? It is what CSNET and BITNET provide to their users now.
   The focus is on the application layer, with the other 6 left to the
   OS and networking software/hardware providers to fight out.

2. CREN should provide leadership in specifying the services and the
   interfaces/protocols necessary. Who writes the code to implement
   the protocol or meet the interface spec could be anyone -
   commercial or volunteer. CREN should facilitate development and
   maintenance of such software, and provide the method of
   distribution to its members.

These are admittedly incomplete thoughts.

Mike Hrybyk
BITNIC