On Tue, 23 Jan 2001 20:57:22 +0000, Maarten ter Huurne wrote:
>Both have different tasks. The file format contains all information needed to
>run the game. The database contains extra info related to the game.
>Not everyone has a permanent net connection. So it's impractical to have an
>emulator retrieve the info needed to run the game from the database. Also,
>there is a privacy issue: emulator users probably don't want the database
>sysop to know exactly what games they play and when they play them. So it's
>not a good idea to put everything in the database.
You definatelly do not understood my idea. The database will not exchange
data need to run the game. It'll only maintain a copy of the most recent
INIs. The file that will be sent to the user is only ONE file, with less
than 100Kb whem uncompressed. This file will have the number of the most
recent version of ALL games. This is WHY I suggested a single number to
the version, and not a enormous field filled with names and dates.
The guy(s) that mantains the database will take care of the standard
package version numbering. Not the user. There should be only ONE official
package version and this meant to be the best one.
More than one version of the package for the same game will only bring
confusion.
Also, this "version database" doesn't need to be download everytime
the guy runs the emulator. It can be done, say, once by week, or only
when the user requests, so he can verify it their packages are up-to-date.
The info needed to the guy to run the game is in HIS machine, not on
the net. What I suggested was an automatic way so the user can be advised
"Hey, there is a new version of this game package!".
>There are many types of related info about a game. Cover scans, game music,
>tips etc. It's impractical to store all of that in the .msx file, both
>because of the size and because it's hard to keep it up-to-date.
I think it's not impratical. It's impratical having dozens of versions of
the same package, each one containing one different information and the
user will not know what of them he needs to use to get the best performance.
The target users are those that DOESN'T know what is inside the .MSX package.
Or the whole thing is standard, or all efforts will be lost.
>Storing URLs
>solves the size problem, but it doesn't solve the up-to-date problem (broken
>URLs are everywhere). So we decided to move all of the related info to the
>web and use a unique ID to retrieve a list of URLs from a database.
You are thinking on having a database with only one file. I'm thinking on
having a full-database with all official .INIs for the latest packages (and
possibly the URL to the package where this INI is stored) and a reduced one
only containing the GameID and the actual (most updated) official PackageID.
The last one will be that the user will download when he wants to verify
if it's packages are up-to-date.
>An additional benefit is that now the file format can be implemented
>independently of the database. If the emulators support the format before the
>database is finished, there is no problem.
The only "lost" to my suggestion will be that the user will have no way
to know if it's package is the latest or not. No information of the
database will be used to run the game. The info to run the game will
be - as it was defined - in the .MSX file.
----- AbraçOS/2, Daniel Caetano ([EMAIL PROTECTED])
/| | | |\
\| ___ |/ OS/2: http://www.quasarbbs.com/daniel/
\/ ----- \/ MSX: http://www.fudeba.cjb.net/
| | Drawings: http://www.djgallery.tsx.org/
-- -- ...Programming to solve the mistery of life!
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
