Re: Ideas for a new A2 site

[jonnosan <jonnosan@gmail.com>]

On Jul 31, 11:31 am, mdj <mdj....@gmail.com> wrote:
> On Jul 30, 7:14 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> > jonnosan wrote:
> > > On Jul 29, 2:27 pm, Alex Lee <ale...@mac.com> wrote:
>
> > >>If you'd like to help out, I suggest you go play Karateka, Captain
> > >>Goodnight, Airheart, Ultima, Transylvania, take 20 to 30 screen grabs
> > >>for each game, saving each screen grab as a .gif or .png (NOT as a
> > >>JPG...it breaks my heart to see screen grabs saved in JPG, completely
> > >>ruining the quality of image with compression artefacts)...and then
> > >>hang tight for another 12 months or so until I MIGHT be ready to put a
> > >>new site together. But that's asking too much, and would create a lot
> > >>of doubling up for people if they take screen grabs of the same games...
>
> > >>Has anyone got any ideas on creating a database on a comprehensive
> > >>archive of screen grabs?
>
> > > What would be helpful here is some standard archive format that
> > > allowed for easy transport and machine parsing of everything to do
> > > with a disk image.
>
> > > For example, a zip archive with the following subdirectories
> > > dsk - one or more dos order dsk images
> > > pic - zero or more screenshots stored as png files
> > > doc - documentation (in any format - eg text files, pdf, html, tif)
>
> > > along with a text file in the top directory with a standard name and
> > > some structured fields for (e.g.) name of program, publisher, disk
> > > format (e.g. dos 3.3/prodos/other), etc. Sort of like the old
> > > FILE_ID.DIZ from back in the day, but with a bit more formal
> > > structure.
>
> > Hmmm.  How about ShrinkIt, or even .zip?
>
> That in conjunction with the XPackage format that is used by many apps
> these days (for instance, Open Office)
>
> Definiing it as such, and including the descriptive "metadata" as XML
> as well would make it extremely easy to present the package on the
> web, as well as make it simple for emulators, etc. to load the
> package. A primary benefit for example would be allowing emulators to
> easily switch between all the disk images relevant to an Application,
> rather than forcing the user to choose the appropriate image file.
>
> It's a lot of work though, particularly in making sure you don't
> design yourself into a corner, and force the next generation to
> replace rather than extend.
>
> Matt

As I see it, the most important decision is working out what metadata
to collect. Get the schema right, and transforming between different
package or archive formats should be pretty mechanical.