Re: what are .sdk archives?

["Charlie" <charlieDOTd@verEYEzon.net>]

"Gregory Weston" <uce@splook.com> wrote in message 
uce-70F166.21323226122007@comcast.dca.giganews.com">news:uce-70F166.21323226122007@comcast.dca.giganews.com...
> In article <okDcj.13327$_o6.5019@trndny06>,
> "Charlie" <charlieDOTd@verEYEzon.net> wrote:
>
>> "Gregory Weston" <uce@splook.com> wrote in message
>> uce-80E76E.17091026122007@comcast.dca.giganews.com">news:uce-80E76E.17091026122007@comcast.dca.giganews.com...
>> > In article <SOycj.17006$HQ6.14297@trndny01>,
>> > "Charlie" <charlieDOTd@verEYEzon.net> wrote:
>> >
>> >> "Michael J. Mahon" <mjmahon@aol.com> wrote in message
>> >> t56dnerBrK49gu_anZ2dnUVZ_jidnZ2d@comcast.com">news:t56dnerBrK49gu_anZ2dnUVZ_jidnZ2d@comcast.com...
>> >> >
>> >> > Snip <
>> >>
>> >> > Have I mentioned how much I wish the Mac would not add forks to
>> >> > files that don't have them?  ;-)
>> >> >
>> >> > -michael
>> >>
>> >> I agree and for that matter I never understood Apple's obsession with
>> >> forked
>> >> files.  They seem to serve no useful purpose and in fact only 
>> >> complicate
>> >> things.
>> >
>> > They serve the purpose of providing a mechanism to attach arbitrary
>> > ancillary data streams to a directory entry without polluting the
>> > primary stream, which may be a standard, commodity format.
>>
>> I'm hard pressed to see that as a "useful" purpose.
>
> And yet every major OS under active development today (as well as more
> than a few defunct ones) ships with a recommended file system that
> includes it.

I am aware that there are other file systems that allow resource forks and 
operating systems that support them but I still feel that forked files are a 
"solution in search of a problem".

Although I'm not particularly knowledgeable on file systems and operating 
systems I have noticed that although NTFS supports forked files, Windows (at 
least through XP) uses them only for a few limited functions and even those 
could easily be handled in a normal non-forked file.

> The power comes not from being able to *write* the arbitrary streams of
> information, but from being able to read them back again and do
> interesting things like filtering. BeOS, for example, included a file
> system interface that let the user define which of the arbitrary named
> forks would show up in a list view. Mail messages were simple text
> files, with several header fields replicated into external named
> streams, stored in a folder configured to show those fields. Right in
> your file system windows, you could sort by the sender, or the date
> sent, or the priority ....

The problem I have with this example and others that I've read in the past 
is that all this can be done (and routinely is) by applications without 
using forked files.  So long as a simple (unforked file) has a standard 
format it is trivial for a program to read only the information it needs to 
do things like filtering.

>> > The
>> > implementation details of the Macintosh resource fork are increasingly
>> > anachronistic, but the abstract benefit of forks is something that most
>> > vendors seem to be agreeing on lately.
>>
>> I suppose I'm just dense, but I don't see any abstract or real benefits 
>> to
>> resource forks.
>
> The benefit to the traditional Mac resource fork specifically was that
> it provided a standardized method of modularizing application and data
> files such that on a resource-starved machine you could load things on
> demand instead of all at once. And, as noted earlier, you could augment
> data files without actually compromising the structure of the data
> stream.

And the same result can be (and is) achieved by placing the extended data on 
a separate file.  And if standardization is the goal then standard file 
formats for the extended data seems to be the way to go since there is no 
accidental loss of data when moving the files to other systems.

> An excerpt from Bruce Horn's discussion of the Resource Manager:
>
> "The Resource Manager was a solution to several problems: managing
> dynamic data for the Finder; factoring out localizable information
> (strings, icons, and so on) from applications, and finally, managing
> memory use as frugally as possible."
>
> More, including unexpected benefits, here:
>
> <http://folklore.org/StoryView.py?project=Macintosh&story=The_Grand_Unifi
> ed_Model.txt>

An interesting read.  However, it doesn't convince me that forks really 
solved anything.  Adding a resource manager to a resource-starved machine so 
that you can separate data kept in different forks seems counter productive. 
Reading and writing forks requires more code in memory and adds a level of 
complexity that is unnecessary.

I remain a skeptic ( you're probably thinking "hard head" :-)

>
>> > And for what it's worth, the only situation I can recall Mac OS adding 
>> > a
>> > resource fork to a file that didn't already have one is when the user
>> > pastes a custom icon onto a file.
>>
>> My experience with resource forks comes from using (and programming) an
>> Apple IIgs.  I've never used a Mac but a recurrent theme on this 
>> newsgroup
>> seems to be that it adds forks to files (disk images) that pass through 
>> it
>> on their way from the internet to an Apple II.
>
> Probably a misunderstanding. Shouldn't be adding forks to the files, but
> it was likely tacking on a small header filled with file system
> metadata. You could think of it as an additional fork, if you wanted,
> but it was really a way for a file that came from a Mac to be robustly
> stored on a weaker file system. It wouldn't be something that "the Mac"
> did itself, but whether it happened and how the user could control it
> would be on the terms of the specific application driving the file
> transfer.

Okay, that could well be what is happening.

Charlie