Re: what are .sdk archives?

[Gregory Weston <uce@splook.com>]

In article <QWUcj.8821$pi7.8633@trndny02>,
 "Charlie" <charlieDOTd@verEYEzon.net> wrote:

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

The trickery is not a problem for the renderer. The trickery is a 
problem for the implementor, necessitated by the fact that the MPEG-2 
Layer III audio format doesn't provide for the embedding of arbitrary 
non-renderable data. Many formats don't.

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

sacrifices performance efficiency that forks offer, ...

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


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

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.


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

G