Re: what are .sdk archives?

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

"Gregory Weston" <uce@splook.com> wrote in message 
uce-727366.08395627122007@comcast.dca.giganews.com">news:uce-727366.08395627122007@comcast.dca.giganews.com...
> In article <2KGcj.9924$yC6.6991@trndny05>,
> "Charlie" <charlieDOTd@verEYEzon.net> wrote:
>
>> "Gregory Weston" <uce@splook.com> wrote in message
>> uce-70F166.21323226122007@comcast.dca.giganews.com">news:uce-70F166.21323226122007@comcast.dca.giganews.com...
>> >> >
>> >> > 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".
>
> The increased adoption of forks is a good indication that a problem
> exists, given that the engineering effort to implement and support them
> is not free and and benefit to paying users, when they exist, is not
> really buzzword worthy. The problem, simply stated, is that there is
> *sometimes* a benefit (or occasionally outright need) to associate
> ancillary data with a file, the contents of which are in a commodity
> data format that inherently disallows the attachment of that data or
> makes it very difficult on a case-by-case basis.

I will conceed that there may be some instances where a forked file would be 
an overall benefit.  I just haven't seen any yet.

> Have you, for example,
> seen how much ID3v2 is complicated by trickery to allow it to pass
> uninterpreted through a streaming renderer?

No, I never looked at the format of ID3v2.  If the trickery you refer to is 
really a problem for the renderer then placing the data in a separate fork 
is one answer but it is not necessarily the best one.  The tag data could be 
placed in a separate file.

>
>> 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.
>
> There's more than one way to implement just about anything. If the task
> is "attach arbitrary amounts and types of data to a single directory
> entry" what superior solution do you propose?

My point is that attaching extended data to a single directory is not a 
worthy task. Putting the extra data in a separate file works well, can be 
read and written with the same tools that are used for all "normal" file 
handling, reduces the chance that data will be accidentally lost during 
transfers to foreign systems and the files are plainly visible to the user.

>
>> > 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. ...
>>
>> 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.
>
> At the cost of greater development effort in each application and,
> typically, reduced responsiveness.

I've found that more development effort is needed to handle resources on a 
fork and I don't see why there would be reduced responsiveness except 
possibly where the data is "hard coded" into a program.  Here again a 
separate data file cures the problem.

> It sucks, but it sucks less than the
> alternatives.
>
>
>> 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.
>
> You're right. With a simple, well-structured format, extracting a single
> piece of data is *usually* not objectively difficult. But the fact that
> something isn't difficult doesn't mean it can't be made easier or that
> there's no benefit to doing so. If it can be even easier (meaning less
> opportunity for error and weird edge cases) and faster (meaning happier
> users) isn't that a good thing?

Yes.

> If I want to build a list of mail
> senders' addresses on the fly, is opening every file and scanning for
> "From: " and then reading to the end of the line and extracting the
> address from whatever else is there - on the fly, remember - really a
> better solution than looping on read_attr(f, "sender_addr")?

No your solution is better but only because the sender addresses are kept 
separately.  They don't have to be on a fork to be separate.

>> > 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.
>
> That sentence suggests to me that you have misunderstood on a
> fundamental level. Physically, forks *are* separate files. They're just
> attached to the same directory entry to reduce clutter and reinforce the
> association.

Well, I've written MS Windows routines to read Apple IIgs (GS/OS-ProDOS) 
resource forks and that would have been pretty hard to do without 
understanding what they are physically.  I've also written Apple IIgs 
programs that use them.  I did this in part to learn about resources and 
forked files.  I didn't just wake up one morning and decide that forked 
files weren't a good thing.  Over many years I saw not one concrete example 
of forked files being the way to go.

I also believe it is confusing to refer to forks as separate files.  But to 
each his own.

>> 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.
>
> And for simple streams like text, or raw audio or pixel data?
>
>> > <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'm honestly not sure how you could have read that article and come away
> with that impression.

Okay, I went back and re-read the article and I see how I got the impression 
that I did.  First I read the article under the impression that the author 
was talking about forked files when he refered to "resource files".  That 
was a mistake on my part.  We were discussing forked files however and the 
article doesn't mention them.  So the part about me being unconvinced 
stands.

> You seem, frankly, to be determined not to
> understand, in which case there's little point in continuing to try.

I'm sorry you feel that way,

Charlie