Let's develop an open-source media archive standard

From: Steve Thatcher <melamy_at_earthlink.net>
Date: Wed Aug 11 20:32:54 2004

I did not say it was the primary purpose. The data blocks work hand in hand with the formatting information.
It is fine to make a standard extensible, but what good does it do if the (I hate the use the word) file can't be gotten without jumping through major hoops because how the data was stored in the image file wasn't extended out to make blocks. If you have to iterate through formatting information to get data then you have to be intimately familiar with the disk format in use. It means any GENERAL utility to read an image file for data access will have to KNOW about all machione supported rather than just getting some type of data identifier and reading the data out.

I think part of the problem here is that the word file is being taken literally to mean filename, size, data, etc. I am using in the context of a block of data. It has NOTHING to do with how the data is on the disk, where it is stored, the recording format, etc. It is just a piece of data...

Sellam in a later email thought that I was proposing that the data be duplicated twice - one for file access and one for format data - NO, that is not what I was talking about. The formatting information contains no data other that what may be necessary for things outside of what is considered a sector on a drive such as address mark, etc(note: this does not preclude sequential data - I am only using this as a specific example in this email).

I am talking about two separate sections inside the same image file. One of the sections contains data blocks. The other has specific formatting information and POINTS to the data in the data blocks. A utility program could then SIMPLY get any type of data out of the image file without the utility being out of date as soon as someone added a new physical format.

I have tried to make this email as clear as possible, so there is no misunderstanding of what I have proposed.

best regards, Steve Thatcher


-----Original Message-----
From: "Dwight K. Elvey" <dwight.elvey_at_amd.com>
Sent: Aug 11, 2004 8:11 PM
To: cctalk_at_classiccmp.org
Subject: RE: Let's develop an open-source media archive standard

>From: "Steve Thatcher" <melamy_at_earthlink.net>
>
>what is wrong with making things easier?
---snip---

Hi
 I'm not saying to make it impossible to do, just that it shouldn't
be considered as a primary purpose. Using an extendable language
like I've suggested, one can add such features. Part of the problem
is that when someone creates the archive, they may not even know
the file structure of the disk. I would expect the specification
to be broad enough to allow such. Still, the primary thing is
to be able to recreate the original material.
 To me this means that any input to some emulator may mean that
it requires some post processing. How would one know what some
some format a particular emulator wanted? How would a person always
know how to read the directory structure and be able to extract
files? If one wanted to work in all cases, I'd expect that the
person writing the emulator would provide the needed post processing
to extract such information. Otherwise, they'd only be able to
read archives of disk that were specifically created for their
system. Those archives that the person didn't know the file
structure would be useless unless.
 Such things are secondary functions. They shouldn't be restricted
from being used, it is just that the primary function should
be to capture the entire information in as close to the original
format as possible. Creating post processors could easily be
done as a separate outside function for special purposes.
Dwight
Received on Wed Aug 11 2004 - 20:32:54 BST