Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!portal!cup.portal.com!MacUserLabs
From: MacUserLabs@cup.portal.com (Stephan - Somogyi)
Newsgroups: comp.sys.mac
Subject: Re: What I'd like to see in the AppleShare of the 90's
Message-ID: <26091@cup.portal.com>
Date: 19 Jan 90 02:38:20 GMT
References: <25184@brunix.UUCP> <25862@cup.portal.com>
  <1990Jan13.151947.15612@phri.nyu.edu> <25941@cup.portal.com>
  <10578@bsu-cs.bsu.edu> <26015@cup.portal.com> <10585@bsu-cs.bsu.edu>
Organization: The Portal System (TM)
Lines: 39

mithomas@bsu-cs.bsu.edu (Michael Thomas Niehaus) writes:
 
>I believe AppleShare was created for sharing files. With a good file
>sharing system, differentiation between data and applications
>shouldn't be needed.
 
You're absolutely right. But the MacOS works the way it does, and that
includes the pseudo-vmem scheme used by the resource mgr. Unless an
app preloads all its code and any other bits it needs, it'll encounter
problems when a server disconnects abruptly.
 
Saying that AShare is for sharing files is all well and good, but not
realistic.
 
I write:
 
> AShare was designed for roughly 10 people/server sharing data.
 
Michael writes:
 
>That may be a good rough estimate for a file server running over
>LocalTalk. For EtherTalk, that number would be increased.  There is
>no limitation in the software.  You just have to ask yourself how
>long you (or the other users) are willing to sit and wait.
 
The operative word is *designed*. The current iteration of AppleShare
was developed with LocalTalk in mind.
 
There is a limitation in the software. 25 nodes or so max per server.
Once you reach that limit you get a message saying 'Too many users
logged on.'
 
Also, we've found here that giving an AShare server more than 2MB RAM
is a waste; it all becomes RAM cache.
 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Stephan Somogyi       Berlin ist 1 Reise wert
NetWorkShop Manager
MacUser	              Any opinions expressed above are mine.