Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!cit-vax!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple
Subject: why we (don't) need AFP 2.0
Summary: Appleshare CDEV is lazy
Message-ID: <12414@cit-vax.Caltech.Edu>
Date: 29 Oct 89 09:43:09 GMT
Sender: news@cit-vax.Caltech.Edu
Reply-To: toddpw@tybalt.caltech.edu.UUCP (Todd P. Whitesel)
Distribution: comp.sys.apple
Organization: California Institute of Technology
Lines: 45

According to Inside Appletalk AFP 2.0 adds some nice protection/backup bits
as well as some other stuff (it's all in boldface anyway), not the least of
which is the definition of the ProDOS filesystem info field. This is reasonable
and the fact that AFP 2.0 allows you to have ProDOS partitions on the server is
nice when you're a school with loads of //e's that are accessing data on the
server via the Workstation Card.

What I don't understand is WHY the ProDOS info had to be defined in the first
place! The ProDOS filetypes are easily encapsulated into AFP (i.e. Mac) file
types, as a table in Inside Appletalk shows. Why doesn't the Appleshare FST
(or even a patch to the ProDOS 8 MLI) just encapsulate the filetype info and
ask the server for a file it would already understand, i.e. $04/xxxx becomes
TEXT/pdos when the AFP packet is sent. This translation (which is done by an
AFP 2.x server if the AFP file info isn't set) is so easy it could have been
done on the workstation card or by the AppleShare FST.

I'm not attacking AFP 2.x at all, I just don't think the current AppleShare FST
should insist on it. (At the size it is right now, who'd notice the extra code
anyway?)

My reasons for beefing are twofold:
	1. It is more robust to require as early a version as possible of the
		server software. This means you can work with more servers.

	2. We have an AlisaShare server that doesn't speak 2.x and I want to
		use the FST on it. If I wanted to use a P8 application on the
		data, I've got a ramdisk for that, and I want to use Finder to
		get the file off the vax.

Also, why were Chooser functions implemented as CDEVs? After working with them
a bit I have found that they clutter my Control Panel and I ended up deleting
everything that was available on the Classic Control Panel. Besides, isn't
there a lot of duplicated code between the AppleShare and Laserwriter CDEVs
(NBP lookup code, interface, and some such)? The new SSW is so big you can't
run AppleShare, LaserWriter, and Appleworks GS together on a 1.25 Meg gs, I've
tried it and it can't load a module even on a new document. There's only 192K
free or something before I attempt that if I remember right.

Todd Whitesel
toddpw @ tybalt.caltech.edu

P.S. Dave- I'll tidy up the quirks list and send it; be warned there's some
	preaching so I'll try edit the offensive parts out and replace them
	with suggestions. (I wrote most of it after installing AppleShare onto
	a disk _other_ than my boot disk with only ONE 3.5 drive.)