Re: what are .sdk archives?

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

"Gregory Weston" <uce@splook.com> wrote in message 
uce-A34B3E.18313001012008@comcast.dca.giganews.com">news:uce-A34B3E.18313001012008@comcast.dca.giganews.com...
> In article <0Zbdj.199$sE5.47@trndny05>,
> "Charlie" <charlieDOTd@verEYEzon.net> wrote:
>
>> "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 <
>>
>> 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.
>
> I'm wondering if we're misunderstanding each other to an increasingly
> greater degree.

The misunderstanding is my fault.  I meant transfers of files to foreign 
file systems.

> Are you here suggesting that a commodity archive format
> be adopted as a standard data container (presumably implicitly supported
> at the FS level), with the main data stream perhaps given a fixed name
> and all ancillary streams given predictable names based on input data
> such as (what would in current scenarios be) the fork name?

No, I'm not suggesting that.

>> > 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.
>
> But getting back to what I said above, that leads to either a
> potentially huge amount of user interaction or a lot of OS magic to
> maintain the relationship. To me it's very suboptimal for the user to
> see, in addition to their foo.txt file, an unbounded collection of other
> files named foo.txt-xattr-SenderName, foo.txt-xattr-SenderAddr,
> foo.txt-xattr-Subject, etc. (It may not even be possible, given that we
> have to deal with limits on the lengths of both filenames and full paths
> in most extant file systems today.) Just having them there buries signal
> under noise. To then either require that the user rename the files, copy
> them en masse or whatever *or* have the OS do so those manipulations
> implicitly just aggravates the situation.

Suboptimal yes, but in my mind better than forks.

>> I doubt though that in your email example that either forks or extra
>> files are necessary.
>
> Your doubt, bluntly, is unfounded. The interface was predicated on the
> notion of an arbitrary app being able to retrieve an arbitrarily named
> piece of data from an arbitrary file. It's a bit chicken-and-egg, but
> what I'm saying is that the solution, which was really quite desirable,
> wouldn't have been viable without the infrastructure of named forks.

Yes, I see your point for an interface designed specifically to use named 
forks.  One designed to read separate named files would work also. But 
doesn't the system have to create the forks (or files) in the first place? 
When it receives an email (or any other kind of data) it could just as 
easily (I think more easily) create a normal unforked file, splitting up the 
data (sender address, etc) in a defined structure within that file.  The 
interface could then expose this structure to the user to manipulate.

My thinking is based on the Apple II systems and not on BeOS or any system 
where the interface exposes the fork names to the user.

In any case I believe that forks aren't worth the problems they cause.

Charlie