toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/29/89)
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.)
mattd@Apple.COM (Matt Deatherage) (10/30/89)
>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 AFP2.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. > Look, Todd, I didn't write this code. But the people who *designed AFP* determined that for it to work correctly with ProDOS, AFP 1.0 would not do. I don't know all their reasons, and I'm not going to stop them from their current engineering work to ask them to write up a defense of it. You can either trust the judgement of people who designed the whole thing that their creation was not robust enough, or you can believe that Apple's just out t make life miserable for its customers. I know the latter not to be true. >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?) > No, you're attacking Apple for evolving a standard they created. The IIgs *could* have been done with an 8-bit microprocessor. Why not use the existing bank-switching technology already available instead of all this new 16-bit stuff? >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. > I agreed. In fact, I stated that if it were possible to use AFP 1.0, we would have done so and not had to update tens of thousands of server customers to a new version (free, for the first six months after AppleShare 2.0 wa released). > 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. > I hope your servers are updated as Apple's were. >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. > You only call them "chooser" functions because that's the way the Macintosh happens to implement them. There may be some duplicated code between the various AppleTalk-related CDevs, but the code for only one CDev is present at any one time (the one that's selected). Others that have been used are marked as purgeable so they're unloaded when memory is needed. The System Software has grown, but the program you're using (AWGS) takes an awful lot of memory on it's own. You seem to be attacking Apple for making system software so that the claim on the AWGS box (requires 1.25 MB) doesn't hold true any longer. But it does hold true, as long as you use the System Software that comes with it. And Apple *clearly* states that using the network capabilities of 5.0 will require more memory than otherwise (about 256K more, according to the box). Apple II AppleShare stuff has *always* required AFP 2.0, even back to ProDOS 16 version 1.6 (the first network release). That was about 14 months ago, and developers were alerted long before then that server changes would have to be made. I'm sorry your server doesn't work, but yelling at Apple that they should have used an older, unsuitable version of the protocol isn't going to make your server work again. AppleShare for the Apple II will not regress to AFP 1.0 because it can't, for reasons I don't know. Now can we please get on to more useful subjects rather than a continued game of "kill the guys who make the computers"? >Todd Whitesel >toddpw @ tybalt.caltech.edu > -- ----------------------------------------------------------------------------- Matt Deatherage, Apple Computer, Inc. | "The opinions expressed in this tome Send PERSONAL mail ONLY (please) to: | should not be construed to imply that Amer. Online: Matt DTS | Apple Computer, Inc., or any of its ThisNet: mattd@apple.com | subsidiaries, in whole or in part, ThatNet: (stuff)!ames!apple!mattd | have any opinion on any subject." Other mail by request only, please. | "So there." -----------------------------------------------------------------------------
rewing@Apple.COM (Richard Ewing) (10/30/89)
(stuff about AFP 2.0 and Alisashare deleted) Now wait a minute! Since when is Alisashare not AFP 2.0 compatible? Ours is, and it's been that way since Decmber of last year. The upgrade was also free, so I'd check with your net administrator to see if the software update was installed on your system (it came on three Mac floppies, not a tape). I use the Vax to store and retrieve stuff from my IIgs all the time, and it works well. -- __________________________________________________________________________ |Disclaimer: Segmentation Fault: Core Dumped. | | | |Internet: REWING@APPLE.COM-----------------------Rick Ewing | |ApplelinkPE & MacNet Soon!------------------Apple Computer, Inc. | |Applelink: EWING--------------------100 Ashford Center North, Suite 100 | |Compu$erve: [76474,1732]--------------------Atlanta, GA 30338 | |GENIE: R.EWING1--------------------------TalkNet: (404) 393-9358 | |USENET: {amdahl,decwrl,sun,unisoft}!apple!rewing | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^