Let's develop an open-source media archive standard

From: Dwight K. Elvey <dwight.elvey_at_amd.com>
Date: Thu Aug 12 13:40:49 2004

>From: "Roger Merchberger" <zmerch_at_30below.com>
>Rumor has it that Vintage Computer Festival may have mentioned these words:
>>On Wed, 11 Aug 2004, Steve Thatcher wrote:
>> > If we create a physical description only and do not abstract the data
>> > then any emulator must understand the OS file structure in order to
>> > retrieve any internal file representation.
>I don't wanna sound like a doofus, but:
>> My idea would make the file
>> > re-creation simple in that the xml image file would be parsed for the
>> > actual file data that an emulator would need. This makes the emulator
>> > easier.
>>You're describing an imagefile that contains a filesystem image, rather
>>than, say, a disk image. This can be accomodated in the spec, but it's a
>>different type of image than what we've been discussing.
>It could be accommodated, but why should it when it would be easier for
>someone to build a converter into an emulator image file?
>This spec (as far as I understand it) is going to be read-only anyway -
>this is for archiving after all. What happens when the emulator tries to
>rewrite the disk image (say, from saving a modified file)? What will happen
>to the original archive?

 I don't see this as being an issue. Once one knew how to
decode the information for such applications that wanted to
extract the data, one could import information into the
image. It would of course require some knowledge of the
data structures used by that system. It would have to know
how to resolve things like logical interleaving and allocating
space by the allocation methods.
>>It's up to emulator writers to read the spec and adapt to it.
>Bam. That hit the thumbnail right on the head. ;-)
>> We'll make
>>the spec as flexible as possible, but first and foremost, the spec is
>>intended to archive images of data media, and not to serve as a universal
>>emulator image format (though it should be able to be used as such).
>I'd like to add that IMHO it should be "read-only" so the emulator doesn't
>destroy the archive when it rewrites certain sectors and/or files.

 I don't see this as an issue. Once one has the archive file in hand,
using it as a method to import external data is surely a valid application.
The concept of read-only is just an OS flag that can be overwritten.
Surely, someone doing this would rename the file or otherwise indicate
that it has change. There is nothing anyone can do to restrict such
actions. Why specify something that can not be enforced? We can recommend
action. We can recommend that there be a field that indicated any change
in the data of an archive and if that change is an overwrite of data
or an enhancement of the data.

>At least that's my take on the deal...
>Roger "Merch" Merchberger
>Roger "Merch" Merchberger --- sysadmin, Iceberg Computers
>Recycling is good, right??? Randomization is better!!!
>If at first you don't succeed, nuclear warhead
>disarmament should *not* be your first career choice.
Received on Thu Aug 12 2004 - 13:40:49 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:36:34 BST