Re: what are .sdk archives?

[Gregory Weston <uce@splook.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 <
> 
> >
> >> 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.

I'm wondering if we're misunderstanding each other to an increasingly 
greater degree. 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?

> > 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.

> 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.