Feature: Defs Filestore

[SakuraIsayeki]

Problem

After a replay-breaking game client update, all downstream implementations are unable to use the latest replays, without either recompiling towards a new library version provided by us (and therefore restarting their services), or otherwise performing strange dynamic linking of our library, which is as esoteric as it is impractical.

Context

Our library recently switched the game client matching part from hardcoded instructions, to dynamic .def file parsing, with these files coming straight from the game client.
A long-standing service (like an API) should never need to restart for such a trivial change, much less require more development and release/deployment formalities. It should be able to ingest such a change during runtime, eliminating its needs for unnecessary restarts.

Solution

In short: We allow the downstream application to run their own .def filestore.
And we provide an implementation.

Currently this is tied to the IDefinitionStore, which provides the means to implement a part of it, but also is responsible for also backing the type mappings.

We plan to make a breakout of the current implementation to a new and yet TBA interface, to allow an easy implementation of a def backing store, which later can then also be implemented by downstream applications (e.g: proprietary network transfers, in-database storage, Azure/AWS, etc.).

The currently envisionned new implementation will consist of a filesystem backing store, whose path can be configured to any local path on a machine, to serve the necessary .def files. This would concurrently be available to the downstream app, as well as the current system that is the library-embedded backing store, where all files are tied to a library version.

Credits

• Idea: @SakuraIsayeki
• Implementation concerns: @SakuraIsayeki @stewieoO

[stewieoO]

Was closed with #30