On Tuesday 23 January 2001 20:51, you wrote:
> I'm not talking about .MSX files database, but a database with
> an "OFFICIAL" PackageID. This PackageID may be used to verify if
> the file is or is not up to date.
That would only work if there is only one package per game, right? I'm not
sure such a centralized approach is what we want.
Also, it would require the emulator (assuming that the update functionality
is in the emulator) to be able to build a new package in which the info file
is replaced. Until now, emulators are only required to read information from
a package, not to modify it, and I would like to keep it that way.
> > I think the database should only provide URLs for info related to a
> > certain GameID. For example, I could query "GameID=snatch Type=music" for
> > Snatcher game music or "GameID=penadv Type=cover" for Penguin Adventure
> > cover scans.
>
> This will be confusing, I think.
Which part do you think is confusing?
> >Some reasons not to store actual .msx files in the database:
> >- bandwidth problems: you can get small amounts of bandwidth for free or
> > for a low price, but huge amounts will cost a lot of money (MEP had this
> > problem)
>
> Only the INF file would be uploaded to the site. The idea is the .MSX
> could be uploaded to some place else, like FUNET, only if the .INF *is not*
> from a know game.
That would decouple the info file from the package. Again, that would only
work if there is only one package.
For example, some ROMs have been modified to run on existing emulators. Many
people (including emulator authors) consider this ugly and prefer to have
unmodified ROMs. It's possible that a modified ROM is spread in a .msx
package, such a package would have an info file describing the MegaROM mapper
of the modified ROM image. When the mistake is noticed and corrected, there
will be a different ROM file and a different MegaROM mapper description in
the info file. The new info file won't work with the old ROM image. That's
why it's not a good idea to separate the info file from the package.
> >- legal problems: there may be a company that doesn't like their games
> > spread and we shouldn't run the risk that the entire database is taken
> > down because of that
>
> Well... they may fight about FUNET also.
You've got a point there. Although on an FTP site it's easier to discuss a
part of it (a subdirectory) than for a database, which isn't that transparant
to the outside world.
> >Also, I don't think an upload function belongs in an emulator. Uploading
> >doesn't belong in the "playing the game" phase, it belongs in the package
> >creation phase.
>
> Good idea. A program to create packages may do this. But the verify for
> version number is a perfect idea. The idea I had was about automatize the
> functions. If the user had to do this "by hand" it'll be just crap, because
> almost no one will use them (almost no one will now they even exist!)
I agree that some kind of auto-update would be useful. I'm just not sure
whether there is a practical way to do it. For now, I think it's best to
include an identifaction of package versions and then later decide exactly
how to use that.
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
