> There's one drawback with this approach: XXX=YYY strings
> must fit on one line. I think that's ok, all multi-line information,
> such as the Comment field, was thrown to the .msx database server.
> We can even remove the quotation marks, Machine="MSX" can
> safely be replaced by Machine=MSX in this new syntax. Strings
> now begin at the "=" and end at CR or LF.

I think using a file format and a database to retrieve all information is a
bit double. I think it should be one or the other. So all information in the
ini (advantage: can easily be expanded, disadvantage: some people probably
don't want to take the effort or creating one for every file they host), or
all information in a database, with the n-bit (I suggest 32-bit)
CRC/checksum as primary key (advantage: you don't need to distribute the ini
file, in fact you don't need the entire fileformat we discuss here,
disadvantage: updates have to be downloaded seperately and someone has to
maintain it).

By the way, it's amazing how much fits on one single line...


> Patriek suggested using CRCs as GameIDs, but I don't think
> this is a good idea. It works fine for ROMs, but what about
> multi-disk games? Should use the CRC from the first disk? From the
> last? Should we append all the disks and take the CRC of the result?
> In this case, in what order should the disks be appended?

Why don't you use the full name of the game as ID? So "Penguin Adventure" is
the unique descriptor. The cracked disk version by xxx should then be
"Penguin Adventure - crack - xxx", or you could create a version field which
can be a number or a string ("original", "cracked") and a dump/crack author
string ("martos"), which alltogether form the game ID. By the way, CRC's are
also a good ID (they should be 32-bit though, with 16-bit CRC's there is too
much chance two games have the same CRC).


> > By the way, I think "us" is not a valid language code. It's probably
> > "en_US" or something like that. After all, the language is still
> > English (although some UK people will deny this ;), US specifies the
> > "dialect" (it's not really a dialect, but I don't know the proper
> > word).
>
> I made a search on the web and couldn't find the RFC.
> If it is not available anywhere, we should make our own
> language codes.

It's there, definately. Look in the references of the assigned numbers. Come
to think of it, I bet it's an ISO or IEEE standard, and not an RFC.


~Grauw





--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html

Reply via email to