Hi,
I've integrated two replies into one.
> > I agree that it is a useful service, but I maintain that it doesn't have
> > to be part of the standard. It is sufficient for the info file to include
> > the ID of the packager and the version of the package.
>
> Everything is needed to implement this on the standard are some bytes on
> the INI file! Just the bytes needed to add something like:
>
> PackageID=43564
>
> or
>
> PackageVersion=34565
>
> I think it will not bother anyone. If you present me ONE reason to
> NOT add this (no, I do not think it'll make the .MSX packages a lot
> larger), say it.
I want to add package identification as well, so we agree on that point. But
in addition to that, I want to include a packager ID.
> I just do not see any reason to add
> Packager=xxxx
> PackageID=dd-mm-yyyy
> This will never be usefull to the emulator (only may be used by
> emulator to show "Oh! The great xxxx was the packager of this package
> in dd-mm-yyyy!")...
Packaging info isn't intended to be used by the emulator, it's for the
package manager. It's possible to integrate a package manager into an
emulator, but it can be a separate program as well.
> or even to know that a package from the same guy
> is newer than another (which means nothing, because the new one may
> be worse than previous... anyone that do programming knows that
> sometimes we break some things). Besides, these infos may be always
> present as comments.
In most cases, newer packages from the same packager are better than older
ones. Besides, "official" packages have the same assumption that a newer
version is better.
> I understand, but I'm not thinking on a MSX Database with a "King"
> controling it, and so on. I'm thinking on a database that everyone helps to
> bring up-to-date. Having such database, instead of creating your own
> "Penguin Adventure Distribution", you will work on improving the current
> Penguin Adventure INI on the database... And if the comunity thinks your
> changes are good, they will be implemented on the "official" version, just
> like happens with any open software.
But open software always has to option of forking. That's what I want to
allow with the packager ID. Having a single packaging project that everyone
contributes to and whose packages are used by 95% of the users sounds like a
very good idea. But I just don't want to force it in the standard.
> The problem with dates and with names is: Which is the best:
>
> [EMAIL PROTECTED]
> PackageID=2000-12-23
>
> or
>
> [EMAIL PROTECTED]
> PackageID=2001-01-23
>
> ???
>
> I really don't know! How an automated program will verify that?
It can't, but this is not what I want.
Let's say that "The MSX Packaging Project" takes the role of "official"
packager with packager ID "msxpack". The database that keeps track of the
latest versions would be part of The MSX Packaging Project. Any package
manager software that connects to this database will only be offered .msx
files with "Packager=msxpack".
But there could also be test releases, before a package goes into the main
database. Those packages could have "Packager=msxpackbeta". To find them, you
connect to a special database that only contains test releases of The MSX
Packaging Project.
And when a user creates his own packages, it's possible to tell them apart
from the official ones: "[EMAIL PROTECTED]" tells the package manager
that this isn't a package released by The MSX Packaging Project. If I think
the screenshot from the official package is ugly, but the majority of the
community doesn't agree with me, I should be allowed to make a package with a
different screenshot.
I'll give some example configurations of the package manager.
A user who just wants to play games:
Packager ID: Server:
msxpack release.msxpack.org
This user only uses released packages from The MSX Packaging Project. This is
the configuration the package manager is distributed with.
This is what my configuration could look like:
Packager ID: Server:
[EMAIL PROTECTED] -
msxpackbeta beta.msxpack.org
msxpack msxpack.mirror.nl
msxpack release.msxpack.org
mr_x msx.whatever.com:8080
The entries on the top of the list have a higher priority than the ones on
the bottom. I prefer my own packages, so they are listed first. I like to
test development packages from The MSX Packaging Project, so the beta package
server is listed on the second place. Then there are two servers for the
official MSX Packaging Project releases, first the Dutch mirror, followed by
the main site. Finally there is some Mr. X who sometimes releases games that
were previously unknown to the world but aren't packaged very well.
When I let the package manager search for updates, it will download an
official replacement for any Mr. X package. Also, it will download beta
versions for any game I have the release version of. But it will not replace
packages I made with official ones.
Bye,
Maarten
--
For info, see http://www.stack.nl/~wynke/MSX/listinfo.html
