17 May
2005
17 May
'05
5:11 p.m.
On Tue, 2005-05-17 at 16:39 -0700, Fred Cisin wrote:
While the goal is certainly simple (to be able to
generate duplicates
of odd diskettes without requiring human manual intervention), there
does not exist a method of describing a disk format in a practical way,
that does not require SOME manual handling of exceptions.
Although the number of exceptions is theoretically finite,
for ANY proposed specification, one or more of us can come
up with an exception. Therefore, it remains necessary to
retain a "comment" field to be able to specify additional
"weirdities", especially if the spec is to be opened up
enough to deal with "copy protected" disks.
Bah, you just need each archive to contain embedded Java source that can
decode the archive's contents... ;-)
There should be some set of standard fields that are common to all disks
though (surfaces and tracks being two that spring to mind), then
there'll be another set that's specific to a particular type of disk. If
it's all semantic data as part of the metadata section then it doesn't
matter so much.
Utils will be able to handle a subset of all possible formats (which I
suppose is infinite), but enough semantic data should be present to
enable a human to deduce the format from the data and write a parser if
needs be. I wouldn't expect we need to go as far as including the spec
for the format within the data itself, but that's kind of nice too (IMHO
storage costs being what they are, it doesn't matter so much if a 160KB
floppy image grows another 10-20KB of ASCII metadata / spec really)
It's getting late here though, so I'm probably talking more crap than
usual :)
cheers
Jules