Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: net.micro.mac Subject: Re: Tops for the PC and Mac (Long) Message-ID: <1065@hoptoad.uucp> Date: Sun, 7-Sep-86 01:25:11 EDT Article-I.D.: hoptoad.1065 Posted: Sun Sep 7 01:25:11 1986 Date-Received: Sun, 7-Sep-86 05:12:53 EDT References: <453@aecom.UUCP> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Distribution: net Organization: Centram Systems, Berkeley Lines: 190 This is a response to Robert Berlinger's review of TOPS. Disclaimer: I am an employee of Centram, not a disinterested observer. When I *was* a disinterested observer, however, I chose to accept employment at Centram largely because I was impressed with TOPS.... >My real problem with it is that it isn't robust. For instance, if the >server or client crashes, TOPS doesn't seem to register that, and either >thinks it is still talking or just hangs. TOPS has gone through months of beta testing in addition to our extensive testing in-house, and we feel that it is very robust. A dialog that says that there are difficulties always comes up within ten to twenty seconds after the connection is broken, if there is a pending client file operation. If there is no pending operation, then the connection may be broken silently, which will cause any further client operations to return an error status. I am not sure what you mean by "thinks it is still talking", but we have not observed the system hanging, nor had such behavior reported to us either in beta test or since release. >Also, some very common actions can bring down the server as far as the >network is concerned. Since TOPS runs as what Centram calles a "hidden >DA", it will stop functioning if you go into the minifinder! Although this >is mentioned in the manual, I think this is a rediculous restriction. That's why we got rid of it! The manual does say that, and it was true in the initial beta release. In the released product, however, TOPS works fine with the MiniFinder. The release notes mention that this has been fixed. >Copying files on the server brings clients to a grinding halt, and >formatting any floppy (although you get a warning) will kill off any >clients you have. Disk initialization does not crash either the server or the client; it just makes the clients wait until the server has finished formatting the disk. Scheduling presents difficulties on the Mac because of the lack of multitasking. We have gone to great lengths to make TOPS run concurrently with virtually all Mac software. Unfortunately, some activities on the Macintosh are very difficult to break into by any means. Disk initialization is time-critical; try breaking into MacsBug during disk initialization, waiting a few seconds, and then returning: the initialization will fail. File copying in the Finder is less problematic, and we are working on allowing TOPS to run concurrently with it; but it may never be possible to run concurrently with disk initialization. >Although the following problems aren't really Centrams fault, they are >issues that have to be dealt with in terms of networks in general. > >1. The Finder was never meant to be used with multiple users per disk. > Problems like trashing desktop files (happens often since there is only > one for all those simultaneous users!), files put in the trash showing > until empty trash is executed, etc. make life difficult. Desktop trashing happens very rarely, but it does happen. Of course, it is easy to recover from. The Finder is being revised within Apple to better support file service environments. I agree, it is a problematic program, not only because of the Desktop file, but because it patches OS traps in hideous ways. It is also rather buggy all by itself, as is usual with large assembly-language programs. Try running it with Heap Scramble sometime and watch the fireworks! (Do this on an unimportant floppy, though...) However, its problems with file service should be rectified in the near future. >2. Copy protected programs don't like to run over the network. In fact, > at least one which I tried (Fontographer with its heavy protection, damn > them) crashed the client system altogether. Of course! In almost all cases it would violate the license agreements on the software to run over the network in this fashion. Should a developer wish to allow such access, we are working on a licensable network copy protection scheme. >3. Lots of programs don't like to run from write protected volumes because > they need to create temp files. In addition, a lot of these programs > create temp files that don't have unique names, so they crash if two > people use them at once from the same folder. This is a problem with the applications. Apple has recommended that Mac programmers use non-conflicting temporary file names, essentially through a simulation of the UN*X mktemp libary routine. However, this advice has been largely ignored. There's not a whole heck of a lot we can do about this. If people don't start to get their act together, we may have to implement a hideous ugly solution by intercepting file system calls on particular files. Obviously, we would rather that developers take the extra few minutes to run their applications correctly. Note also that the Mac OS (specifically, the Launch trap and the Finder) does not support the same file being launched more than once, yet. >Now on to the PC end. > >Although TOPS is supposed make the differences between OSs seem >transparent, it doesn't do a very good job of it. It does a pretty good >job with handling the file naming issue (DOS is 8.3 with no blanks, Mac is >31 with blanks, etc.). Thanks! That's the part I did. >However, a simple thing like being able to make a >copy of a mac application residing on the IBM from the IBM doesn't work. >This is because Centram split up the data and resource forks into two >separate DOS files, with the resource fork being hidden (making them >contiguous would make more sense to me but there must have been some good >reason not to do that). So you can't copy any file that has a resource >fork properly. I think it's pretty obvious why they can't be in the same file. This is not file transfer, it's file service. That means that a file is not a static entity; it can grow or shrink, and either or both forks must be able to change in size efficiently. This can't happen if you lump them both together into one file. As for copying resource forks, we are writing a TOPSCOPY utility, but it didn't make it out in time for the release. Usually, you only need to do this from the Mac in any case, and this works fine. >On the DOS version, when you go to publish a volume, it runs a program >called XSYNC. I'm not exactly sure why they need to run it, but it seems >to do a tree find from the directory you are publishing on down. >Publishing a 20 Meg hard disk with lots of file took between 5 and 10 >minutes. THIS IS REDICULOUS! And unneccessary. The naive user interface, TOPSMENU, does always invoke XSYNC. We expect that if you are publishing a whole hard disk, you will do it fairly often, and so will set up a batch file that publishes it using the TOPS commands. The command language interface (which you would use in a batch file) does not do the XSYNC unless you ask it to, and the XSYNC does not need to be done every time. >We tried their simple example of creating a lotus spreadsheet and then >reading it in with Excel. The IBM crashed as soon as we tried to access >the spreadsheet from the Mac. (We subsequently got this to work, who knows >why.) Great. We do this all the time, and this has never happened. It only happened once to you. I see no reason to assume TOPS is at fault. >When using the IBM as a client to a server Mac, you get full hierarchical >access to HFS volumes. When you try to do this in the opposite direction, >you only get an MFS volume. Why? Who knows, it doesn't say why in the >manual. In HFS, Apple inflicted on the world a monster called "directory ids". Not only does each directory have a name, it has a permanent number. This is not really a bad idea in itself, but it creates problems when interfacing to other operating systems. The problem is not insurmountable, and eventually there will be two-way HFS communication between the Mac and MS/DOS; but it is tricky, and as a result this didn't make it into the initial release. Note that there is a similar problem on the UN*X server. Inodes correspond to directory IDs, but without kernel hacks there is no way to access the inode numbers when you need to. Again, this is all because of the need to support Apple's HFS completely. >Aside from all these problems, it generally doesn't do much! It doesn't >have an email application, it doesn't have a "chat" mode, and no spooler >either. Compared to some of the DOS compatible networks I've heard about, >I'd say this is a serious lack of functionality. TOPS is a file service product, and has always been represented as such. Now that most of the work on TOPS is done, we are moving on to other network products, including the three you mentioned, remote terminal service to Internet hosts, and other keen things. >As you can tell, I'm not satisfied. I don't see any reason why it can't be >good -- it just needs more work. If Centram keeps at it, it may evolve >into something useful. At this point, I'd be scared to share data with it. I don't know what your application is, but your fears are unfounded. To cite just one example, as mentioned in MacWorld magazine, Martin Marietta is using TOPS in their space station design project. We have hundreds of satisfied customers and many rave reviews. Many of your problems were caused by cursory reading of the documentation and could have been resolved by a single call to our support personnel. Other problems, such as the MiniFinder "problem" which does not exist in the released product, were apparently brought up not because you actually encountered them, but for unknown reasons of your own. TOPS is not perfect; no software is. But it is transparent, simple, robust, and extremely useful for file sharing applications. -- Tim Maroney, Electronic Village Idiot and Certified Catholic Theologian {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa) Die daily.