rimpack, a mod registry (and manager) idea

Started by plloyd, July 09, 2016, 02:53:48 AM

Previous topic - Next topic

plloyd

I'd like to share my older idea of a mod registry for Rimworld inspired by the many other package managers in the world and would like to ask if there is any interest and if its worth to pursue the idea.

The idea is to use a similar version of the npm package file format (see https://docs.npmjs.com/getting-started/using-a-package.json). The adapted version of this format would look something like this:

Code (package.json) Select

{
  "name": "package-name",
  "version": "0.1.2-semver",
  "description": "a short description of the modification.",
  "keywords": [ "example" ],
  "homepage": "http://somwhere",
  "bugs": "http://somewhere/bugtracker",
  "license": "MIT",
  "author": { "name": "example man", "email": "[email protected]" },
  "contributors": [ { "name": "another one" } ],
  "repository": "https://somewhere.org",
  "dependencies": { "another-mod": "0.0.0" },
  "environment": {},
  "actions": {
    "install": {
      "instructions": [
        { "type": "extract", "options": { "target": "mod://package-name" } },
        { "type": "move", "options": { "source": "mod://package-name", "target": "rimworld://mods/package-name" } },
        { "type": "mod", "options": { "activate": "example-mod" } }
      ]
    },
    "activate": {
      "instructions": [
        { "type": "script", "options": { "src": "activate.js" } }
      ]
    }
  }
}


The file is used by the registry to obtain and to resolve dependencies of the mod. In addition if contains meta information abouth mod version, author and so on. The very heart are the actions usable by a mod manager to install/uninstall, activate/deactivate, ... a specific mod.

The instructions are using either a number of built-in instructions like "extract", "move" or "mod", an arbitrary script that is running within a sandboxed environment to prevent security issues or a combination of the two.

The idea is to leverage existing infrastructure to host the package definitions. This means this Releases board of the Ludeon forum. A separate infrastructure would be also possible but I would prefer the first one.

Advantages of a forum-based infrastructure

  • Uses existing infrastructure
  • No additional registration and authentication for mod authors requires
  • Uses existing software to make sure only the mod author can modify the package.
  • Easy setup for each mod author[/i]
Advantages of an own infrastructure

  • Possibly faster as a single-purpose server could handle the requests
  • No parsing of the SMF board output necessary and therefore possibly less error-prone

The first solution has despite its disadvantages some charm to me as it requires a minimal setup for the package registry itself. A mod author would mark own modifications usable by the mod manager by adding a tag to his/her release thread.
E. g. instead of "[A13] My very own mod", "[A13] [rimpack] My very own mod". If the thread title contains the rimpack mod, the mod author edits its start post to contain a code area with the package definition shown above to publish it.

However the solution is only possible if a ludeon official give its blessings because to obtain the package information from the releases board requires several HTTP GET requests to obtain all information. At the moment of my tests a single page inside the releases board is about 8.7 KB large. There are 16 pages in the board. To scan all information from it would result in 16 * 8.7KB = 139 KB. In addition each discovered rimpack mod requires about ~15KB (heavily depends on the textual content of the posts in the first page of the thread) to load from the forum.

Each page of the release board contains topics for possibly 20 modifications. If all modifications would be rimpack compatible, the total sum of additional network traffic imposed by a forum-based infrastructure would be 16 * 20 * 24KB = 7.680 KB for each scan. In addition to the traffic the server load itself increases as the SMF forum software has to render each page.

This means additional mechanisms like caching and diffing is required if scanning a forum based mod registry to reduce the amount of requests and traffic. Its possible to cache information after an initial scan and to use the "Last post" date/time combination to determine which information of the cache is outdated or not.

What are you guys thinking. Is a forum based mod registry worth trying?