[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
what info should a dsk image archive store?
- Subject: what info should a dsk image archive store?
- From: jonnosan <jonnosan@gmail.com>
- Date: Tue, 31 Jul 2007 03:11:55 -0700
- Complaints-to: groups-abuse@google.com
- Injection-info: i13g2000prf.googlegroups.com; posting-host=124.183.22.177; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0
- Newsgroups: comp.sys.apple2
- Organization: http://groups.google.com
- User-agent: G2/1.0
- Xref: g2news2.google.com comp.sys.apple2:1973
Following on from topics touched on in '"Ideas for a new A2 site",
I've been thinking about what sort of info a good archive would store
about each disk image.
What I have in mind is a zip file or equivalent that contains one or
more dsk/po/nib images, along with metadata and other relevant
material (e.g. screen shots, scans of box covers & manuals, soft
dox).
Ideally this format would be:
- easy for a user to put together offline (either by hand or with the
help of an application)
- easy for an online archive to import
Data stored should include data needed to add to a browsable catalogue
of images. For commercial applications, that information will include:
- Application Name
- Application Publisher
- Application Author(s) (if known)
- Year of publication
- Application Category (needs to have some kind of constrained and
structured list of categories e.g. "Applications/Word Processor"
"Games/Arcade"
Since most images for commercial applications will be cracks, other
interesting information to record is:
- how 'clean' a crack is it? not sure how to quantify this - at one
extreme are disks that were COPYAble just by disabling checksum
validation, at the other extreme would be a pirate production with a
custom menu and a bunch of disparate games with trainers.
- what type of protection was used?
- what group/cracker released the disk?
What else should be captured?
Have collectors on other platforms already addressed this same issue?