Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!pro-houston.cts.com!dkl
From: dkl@pro-houston.cts.com (David Karl Leikam)
Newsgroups: comp.sys.apple
Subject: Re: FST Idea (was Re: FST's)
Message-ID: <2843.cortland.info-apple@pro-houston>
Date: 22 Nov 89 16:58:32 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 73

In-Reply-To: message from mattd@apple.com

In CS-ID: #2843.cortland/info-apple@pro-houston, mattd@apple.com (Matt
Deatherage) writes;

> There's a distinct difference between doing something the system does not do
> (like writing a new networking protocol or a user toolset for your
> application)
> and doing something reserved for the system (like writing an FST or stealing a
> system toolset number).

   Yes, there's a difference. But _why_ reserve writing FST's, for the system?
The toolset numbers are a different case, but the FST's seem like the software
analogy to a hardware mass-storage device or disk drive. Does it make any
sense to say "Nobody can build a harder for Apple but Apple?"


>Although people writing their own FSTs (hacking them out) might find
something
>that's usefl to thm and others, the fact remains that there are basic
>differences between file systems, and applying an abstract system to a real,
>physical file system can result in unforeseen difficulties that would require
>changes to GS/OS.


  Well and good, but why can't we call that (changes to GS/OS) a "boundary",
past which said third party cannot go, and leave it at that? This seems to me
to make good sense: "Here are the FST guidelines and interface points. If what
you're trying to do requires any change beyond this, you're S.O.L., as far as
Apple Computer is concerned. Other tthan that sort of change, happy hacking."
Then, leave it up to the hackers  to find a way, or work around the
gguidelines as stated. Wouldn't this meet the objection?

  Unless, of course, you're saying that there's _Nothing_ stable about FST
structures and interfaces, in which case, back to my original question: why
split 'em out from the OS itself? If they must change every time the OS
changes, then what we have are little better than patches, or hacks into the
original code. Why dignify this with an implied structure and order that ain't
there?


>*Even if this were not true*, there are other problems.  If I write an HFS
FST
>that handles GS/OS attributes one way (suppose I keep the file type and the
>auxiliary type in the file type and creator type fields, instead of doing the
>filetype translation that Apple's done in Apple File Exchange, DuplicateIIgs
>and the AppleShare code) and Apple releases an HFS FST that handles these
>attributes a *different* way, most of the world is going to use Apple's way,
>suddenly have several disks (or worse, a hard drive) full of information that
>they have no way to translate into something the wold uses(you can't let
>GS/OS translate it; you can't have two FSTs for one volume).


        In such a case, and if there's a really impossible incompatibility,
why wouldn't such a person merely keep using the old FST, and just not install
Apple's new  one? 

   And as for having multiple volumes/harders full of incompatible files, why
exactly would this happen?  The whole point of the exercise is to move
something over to, say, the Mac, in order to use it there. Suppose this is a
font we're talking about, for example. The original GS version is unchanged,
and it continues to work just fine with old or new GS/OS. The translated
version is over on the Mac, and it works just fine with  Finder, regardless of
version.  Where is the problem in exactly _how_ it got to the Mac? The point
is to use this ffont on the Mac, not to make sure you can somehow yank it
back. Why would you want to? And if it's adhered to Finder specifications well
enough that it's useable, why wouldn't it be _possible_ to pull it back with
the new FST, anyway?  Am I missing something?


UUCP: crash!pro-houston!dkl
ARPA: crash!pro-houston!dkl@nosc.mil
INET: dkl@pro-houston.cts.com