Misspelling in OpenBveApi.Packages

zbx1425 commented 4 years ago

Description

All "recommendation" in OpenBVEApi, and OpenBVE itself, related to packages, are misspelled as "reccomendation". It should have had double M but had double C instead.

Appearance (Including but not limited to)

OpenBveApi.Packages.Package OpenBVE/UserInterface/formMain.Packages.cs

Personal

I wonder if it is intentional, and if it is possible to make such api-level change. Is it, or will it be a wontfix?

leezer3 commented 4 years ago

Don't know.

I don't think anyone else is consuming the packages API at the minute, but thats something I stand to be corrected on.....

zbx1425 commented 4 years ago

I am willing to consume the api as S520 and I are writing the https://github.com/BVEContentService/obpkg . Since I have no idea how this api is to be called I copied-pasted the code from formMain.Packages.cs, and I hope it would work... :D It would not be a problem for (at least me) though. As I have planned to use reflection already (since I hope to extend the usage of this tool and port it to BVE5, where OpenBVEApi is not requied), working around this would be simple.

leezer3 commented 4 years ago

In general, the API is at the minute highly simplistic.

It provides methods to compress, extract, find dependency lists etc. but they're non-blocking and avoid throwing exceptions. The database itself is a simple serialised XML file.

Basically, I intended it as a lightweight addition / graphical interface to a standard ZIP file (much like the roots of the Bethseda FOMOD) as Michelle's original tool was unhelpful at best for non-technical users. It was also important at the time that this still was able to be extracted as per a standard ZIP without this version of OpenBVE. That concern I think is somewhat less now, but should still be considered.

zbx1425 commented 4 years ago

I am, ehh, a bit confused about the directory structure and version handling of the package. So as I understand, multiple packages can share the same GUID with different versions. And when installing a package with the same GUID, no matter upgrading, reinstalling or degrading, the user will always be presented with two options? One is directly extracting without removing any files, and one is removing the package and all its dependents and installing the new one?

Anyway, the version handling is driving my dumb brain mad... I would kindly ask you to join the development of obpkg, as I am not familiar at all with this api. I have already get nearly all the networking and metadata downloading stuffs to work correctly, so the client-side dependency resolving is the major problem right now.

leezer3 commented 4 years ago

You're over-complicating it, or at least looking for things the current API simply doesn't do.

Version handling is simple:

The GUID uniquely identifies the package, nothing more.
A call should first be made to the package info method, which in turn returns the version, a list of dependancies etc.
Versions & dependancies- These are entirely left up to the consuming application.
Similarly, file replacement is entirely the problem of the consuming application.

In essence, the current API system is very little more than a slightly fancier ZIP extraction interface. The two options you mention are what has been implemented into the current UI, which maintains the database of installed packages and files.

zbx1425 commented 4 years ago

Ehh... If I select that "replace a existing package" when creating a package, wouldn't it share the same GUID with the one being replaced? So in that way there might be multiple versions of packages with a same GUID. And since the developer can select the minimum and maximum versions of the package to depend on, that makes version handling a problem. The server will be required to serve multiple versions of a package. And my mind began to fall into completely chaos once I started thinking of circular dependency, conflicting dependency (Pack A requires "exactly" ver 1 of pack C while Pack B requires ver 2), etc. Especially when I am to write a program that is supposed to try to resolve them automatically. As a package manager should have the ability to automatically resolve the dependencies, and automatically update the packages, that makes things grow complex. I am actually a bit willing to ask you to give me a hand. As this is a project for the entire community and I wish it can be integrated into openBVE itself with a nice GUI interface for easier access. As the things are growing complex, I am feeling unqualified for such a project, since I have to say as a senior high student I had little experience on developing. Mr. S520 is out of free time right now. I would just abandon it for a while and wait until Mr. S520 gets more time, if you are not willing to participate.

leezer3 / OpenBVE