archive file format exmaple

From: Steve Thatcher <melamy_at_earthlink.net>
Date: Thu Aug 12 07:16:55 2004

the keyword arrangement was just a waking thought this morning and is not cast in codecrete.

Required fields is definitely a good thing as long as the info is really necessary.

The only data that was in the media section was data that was specific to to media such as fill bytes, address marks, etc.

Also, I kept a sub block arrangement because a single datablock was supposed to represent a complete data entity such as a file, boot routine, OS itself for example. In order to retrieve any block of data, one only had to find a "datablock" and then concatanate the dataitems.

best regards, Steve Thatcher

-----Original Message-----
From: Jules Richardson <julesrichardsonuk_at_yahoo.co.uk>
Sent: Aug 12, 2004 7:50 AM
To: cctalk_at_classiccmp.org
Subject: Re: archive file format exmaple

On Thu, 2004-08-12 at 11:11, Steve Thatcher wrote:
> here is a "crude" example of what I was talking about.
> [snip]

That looks good. How's about moving things like author into the
definitions section? I'm not sure that it belongs at the top level, but
more in the section containing archive info (description, creation date
etc.)

I'd suggest making certain fields mandatory in what you've called the
definitions section. People tend to be lazy, which means the temptation
is there to create an archive and not bother to include much of the
information, thinking that they'll know what it is a few years down the
line. We've all be caught out by that one! (author, date, description
are good candidates for mandatory fields; there'll be others too)

I'm not so sure about having the actual data within the archive element;
I'd rather have it afterwards. Data in your datamap section still points
to chunks of data, using whatever scheme is understood by the
storage/compression system used by the archive. But then the possibility
is there for using an encoding method that doesn't mix with XML data if
needs be. It also makes it easy to scan the archive section by eye as
it's not mixed up with huge chunks of encoded media data. Actually, you
could probably build collections of media archives (say for some common
platform) all within the same file that way, without breaking the format
- the data in the datamap section of the first archive section just
points to other archives within the same file. That's kinda neat.

eg. (simplifying a little for example purposes):

<archive image file version="1.0">
  <definitions>
      ... as before ...
  </defintions>
  <media>
     ... as before ...
  </media>
  <datamap>
    <head physical="0">
      <track physical="0">
        <sector logical="1" physical="4" id="DB1" />
        <sector logical="2" physical="8" id="DB2" />
       ...
     </track>
    </head>
  </datamap>
</archive>
<datablock id="DB1" type="boot">
  ....
</datablock>
<datablock id="DB2" type="boot">
  ....
</datablock>

.. that way anything following the archive section doesn't have to be
XML data even, providing the definition within the datamap section for
the encoding/compression scheme used by the archive can reach it. It
might be zipped data, other archive definitions, whatever.

cheers,

Jules
Received on Thu Aug 12 2004 - 07:16:55 BST

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