[ in response to Derek, but I feel a need to step in here ]
>TCP/IP based netwroks, which still largely use NFS.
"still" ? What, pray tell, is going to replace it? Certainly not AppleShare.
NFS has become _the_ defacto standard for file serving on IP networks.
(I say IP here, not TCP/IP. NFS does not use TCP, rather it uses UDP which
is no more than a switchboard/multiplexer for user level IP access.)
NFS certainly has its problems, but the simple fact is that virtually every
SPARCstation out there can become an NFS server in about five minutes of the
superuser's time. That is about as close to "plug and play" as most unix
facilities can get.
FYI: NFS and AppleShare both suffer from the same performance problem: round
trip delay on synchronous data exchanges of 4K or so of data. This keeps them
simple but it not at all efficient compared to transferring an entire file
with TCP. Since many programs need to seek around in files a lot, TCP based
file serving that is transparent and mountable (as opposed to actual FTP
utilities) is inherently not clean to implement and is still pretty rare.
One implementation that I do know of is "touch" on the NeXT.
>You might well consider
>the hassles of mail, which is a mess at the moment. Start adding sound, graphicsand other non-ascii information and you are really into a mess of problems.
This is pretty irrelevant, really. AppleTalk vs. TCP/IP does not have anything
to do with mail hassles. You forgot to mention line length, by the way; I see
your last line here is way longer than 80 characters. I'm surprised it made it
through intact.
The problem of adding non-ascii information to a facility that traditionally
supports only ascii data is universal. The only way to fix it is to do either
of two things: adopt standards for encoding non-ascii data into mail (these
exist, but not universally by a long shot), or CHANGE THE MAIL SYSTEM ITSELF.
The lower level network protocols are irrelevant except in logistic terms,
i.e. new software may at first be only implemented on a single protocol family.
>the networks I have seen are somewhat difficult to use and to maintain. In
>particular, their problems can't be dealt with by having the occasional
>consultant dropping in.
I am willing to bet that if those sites had called in a consultant when they
set things up in the FIRST place, they wouldn't be having so many problems
later on!! To many people are content to hack until things seem to work, and
do not attempt to understand what they are working with. This is stupid, but
it happens far too often.
> But, there is no need
>for it just to link into the Internet. Here's a simpler way. Use an Appletalk
>based network and one Mac with Apple's new Internet Router software, which
>converts TCP/IP to Appletalk and vice versa.
Yo, listen up. Apple's Internet Router doesn't automatically give me Telnet
and FTP. Implementing TCP/IP on the Apple _does_. To actually talk to the
Internet proper, I need a gateway of some kind no matter what. BTW, I would
use something besides Internet Router, which ties up a Mac and is not as
efficient as a dedicated box like a Shiva FastPath (the 5 is great, I'll
swear by it) or a Cayman Gatorbox.
There is no such thing as "converting TCP/IP to AppleTalk". There is
"converting TCP/IP to TCP/IP _inside_ AppleTalk (and back)" and also
"converting AppleTalk into AppleTalk _inside_ TCP/IP (and back)". The former
you use so you can use FTP and Telnet from an AppleTalk network, since the
analogous facilities DO NOT YET EXIST in the AppleTalk protocol family (ADSP
is only the first step). The latter is used to link two otherwise isolated
AppleTalk networks via a TCP/IP capable network.
>though, as my network was set up without reading anything.
I rest my case !! :) AppleTalk was designed specifically to be plug and play,
but in doing so it lacks heavily in the scalability department. The internet
protocols and administration have been designed so that the most complex
administration is central and the simpler administration is distributed. This
system is not perfect, but it has been very successful and will continue to
be so, in spite of ignorance and cluelessness on the part of institutions.
>The point is how to link small networks, not have one big one using the same
>unfriendly software. The solution exists now. It is largely Appletalk based,
>and if you insist on TCP/IP, you simply use a (software) gateway.
This either makes no sense, or is totally obvious. The "one big one" is an
addressing illusion created intentionally by the architecture of TCP/IP.
The _reality_ was and always will be a bunch of small to mid-size networks
connected together via gateways of all kinds, using protocols of all kinds,
except that they all speak IP in addition to whatever else they use. The
internet is not a physical entity, rather it is a data delivery service made
up of thousands of cooperating and mutually connected networks that will obey
