Path: utzoo!attcan!uunet!mcvax!unido!iraun1!smurf!urlichs
From: urlichs@smurf.ira.uka.de (Matthias Urlichs)
Newsgroups: comp.protocols.appletalk
Subject: Re: TOPS, AFP, et al
Message-ID: <939@smurf.ira.uka.de>
Date: 8 May 89 21:33:44 GMT
References: <10660@ibmpcug.UUCP> <1865@ccnysci.UUCP>
Reply-To: urlichs@smurf.ira.uka.de (Matthias Urlichs)
Organization: University of Karlsruhe, FRG
Lines: 53

In comp.protocols.appletalk alexis@ccnysci.UUCP (Alexis Rosen) writes:
< 
< In article <gYK=wvy00WB7AiCG93@andrew.cmu.edu> dp22+@andrew.cmu.edu
< (David Bruce Pinkus) writes:
< >     Has anybody had any success using the Multi-User version of FoxBase
< >with TOPS?  I haven't seen the Multi-user version, but if it can be done,
< >I'd appreciate some advice/info.
< 
< TOPS does not support AFP, and will therefore not support Fox. In fact, as far
< as I can determine from lengthy discussions with TOPS tech types, TOPS does
< not support any kind of byte-range or record locking whatsoever. (This is why
< 4D tends to crash more frequently under TOPS than AppleShare or single-user:
< It knows it's not getting AFP so it does some bogus page-locking instead.)
< Fox chose not to do it at all rather than do it wrong.
< 
Actually, one can use the range locking calls with TOPS. Unfortunately
the TOPS people did several things wrong:
- Program A opens a file, locks range x to y.
  Program B opens the same file, reads that range _without_ locking it
  first. Result under AppleShare: Program B gets an error result.
  Result under TOPS: Program B can read (and write --> corrupt) the file.
- We now open a file, lock some bytes, close the file, open it again.
  Wonder of wonders, the range is _still_ locked.
(Disclaimer: This was true for version 1 of TOPS but if they had fixed it,
FoxBase wouldn't have problems, so I assume it's still broken.)

< TOPS claims that they will support the byte-range locking features of AFP
< by the end of the year. This would make them compatible with FoxBase.
:-) :-) :-) If they need that much time to put a thing like that into
their protocol (just checking for locked ranges on _Read and _Write, right?)
then they do have some very serious problems.

They should have even less of a problem under System 7 (apart from getting 
TOPS to work at all, of course :-) if/when the Mac OS supports range locking
for local disks. APPLE, PLEASE DO IT!
< 
< It is my carefully considered opinion that TOPS is in the same position now
< that MacServe was in three years ago: They currently dominate the market,
< and they're throwing it all away through marketing stupidity and bad
< technological decisions. I expect to see TOPS dwindle to a small minority
< of the market within 24 months.

Guess how hard it is to write an AppleShare server to run under
MultiFinder (or as a driver) concurrently with your normal work?
Expect to see such a beast "soon". (Whenever that may be.)
What you won't get is password protection on a per volume basis (the way TOPS
does it). AFP provides the framework for it, but the AppleShare client
for the Mac does not implement it. :-(

Guess how much faster than TOPS such a beast would be? :-)
-- 
Matthias Urlichs -- Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- FRG
urlichs@smurf.ira.uka.de -- ++49+721-621127@PTT