Idea for C= Package Management system

[Guest]

(This is cross-posted from Comp.Sys.CBM and my blog at http://www.paytonbyrd.com)

One of the really frustrating things about being a C= collector is the vast variety of file formats that software is bundled in, and the myriad tools necessary to deal with said formats.  I've often thought that it would be great if there was a simple way of finding and getting C= files, and then a simple way of getting those files to the C= or emulator for usage.

My idea is for an XML-based Commodore File Package (call it XCFP) that would be used to describe an archive and to hold the binary data of that archive with each file in the archive being a BASE64 CDATA element within the XML file.  The basic namespace describing the archive could be extended with functionality for allowing differing behaviors for different types of files.  

For example, a BASIC program could have a CBMBasic element that contains the text of the BASIC listing, and attributes for declaring the supported systems, and even sub-elements that could be used to allow different lines of code for specific systems.  When the archive is read, it would be required to specify the target system and the BASIC file would be extracted and tokenized for the target system.  In such a manner, a disk image could be easily generated from the contents of one or more archives, or an individual file selected from the archive, written as a .PRG file and then executed in VICE.

A separate program would be available for managing the XCFP archives that would work in conjunction with OpenCBM to directly read/write from real CBM drives for easy portability of the contents of archives to a real CBM machine.  The system would be completely interface-based and would allow for any file to be rendered to any device that implements the interface through plugins, so someone could write a plugin to generate WAV files of tapes, etc.

Another aspect of the tool would be to leverage the Star Utilities tools to extract the contents of Lynx, Arc and other archive types and repackage them as XCFP archives.  The XCFP files themselves would be compressed using open source ZIP libraries to save space and network bandwidth.

One of the really cool things I think we can accomplish with a system like this is a top-notch content portal that could be used as an XCFP distribution system.  The program would use Web Services to search, retrieve and upload XCFP packages.  

As long as the client can be run in Mono 1.2, Linux and MacOS X users would not be left out in the cold, either.

To undertake such a project, I would need the help of a couple of really talented and motivated people in the C= community.  I do not want something like this to be seen as "Payton's pet project".  This is something I feel is a real benefit for the entire C= community and as such I really think it's a worthwhile endeavor, or I wouldn't be putting this out there.

[Brendon]

Hmmm...   would not this be already duplicating what's already available in D64, D71, D81, CRT & TAP images ? Or am I completely missing the your point here ?

I'm not 100% certain that this just wouldn't add complications to the existing foemats is all.

Brendon

[Guest]

Hmmm...   would not this be already duplicating what's already available in D64, D71, D81, CRT & TAP images ? Or am I completely missing the your point here ?

I'm not 100% certain that this just wouldn't add complications to the existing foemats is all.

Brendon

The capabilities of this system would go way beyond the disk images.  This isn't a replacement for disk images, but a way of packaging together multiple related files, and to describe those files in both a machine-readable and human-readable format.