Re: what are .sdk archives?

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

"Gregory Weston" <uce@splook.com> wrote in message 
uce-374A13.08265128122007@comcast.dca.giganews.com">news:uce-374A13.08265128122007@comcast.dca.giganews.com...
> In article <QWUcj.8821$pi7.8633@trndny02>,
> "Charlie" <charlieDOTd@verEYEzon.net> wrote:

> snip <

>
>> reduces the chance that data will be accidentally lost during
>> transfers to foreign systems and the files are plainly visible to the 
>> user.
>
> Actually these last two points are quite troublesome. I'd argue that
> storing the extra data in a logically separate file *increases* the
> chance that the metadata will be dissociated from the primary data
> stream. If they're separate files, then maintaining the association
> requires either a unbounded amount of user effort or a lot of visible
> (and likely confusing) "magic" on the part of the OS. Imagine: "What the
> hell? I moved this file from directory a to directory b and 17 other
> files came along with it. That's not what I wanted." Try explaining that
> one to grandma.
>

One this point I will, at least partially, agree with you.  Large numbers of 
files, I believe, are best transferred in archive files like .zip or 
shrinkit files.

> snip <

>> 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.
>
> You're conflating two concepts that are really distinct. Resources are
> not forks. Resources don't need to be in a separate fork, and forks
> don't need to be structured as something akin to a resource map.

That was not my intention.  I was using Apple's own definitions from the 
Apple IIgs GS/OS Reference (copyright 1990) page 17 under Extended files 
"The two different byte sequences of an extended file are called the data 
fork and the resource fork."  The definition goes on to explain that the 
forks have no predefined format.  I was using the term "resources" to mean 
any data found on what Apple calls a "resource fork".

>
>> > 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.
>
> Where would they be, then? You really want each e-mail file to be
> accompanied by an arbitrary number of visible ancillary files
> representing single headers?

Yes, I believe it is preferable, to forks.  What you see as clutter I see as 
an open (visible to the user) file system. I doubt though that in your email 
example that either forks or extra files are necessary.

Charlie