Discussion: usage of umu-database

[Root-Core]

CC Open-Wine-Components/umu-database#39

We use the URL umu.openwinecomponents.org to look up the title of the game in case the umu-id is set and we don't know it yet.
We use this for logging purposes only, I think.

umu-protonfixes/fix.py

Lines 59 to 72 in 2348f5d

	# Fallback to 'none', if STORE isn't set
	store = os.getenv('STORE', 'none')
	url = f'https://umu.openwinecomponents.org/umu_api.php?umu_id={os.environ["UMU_ID"]}&store={store}'
	headers = {'User-Agent': 'Mozilla/5.0'}
	req = urllib.request.Request(url, headers=headers)
	with urllib.request.urlopen(req, timeout=5) as response:
	data = response.read()
	json_data = json.loads(data)
	title = json_data[0]['title']
	with open(
	os.environ['WINEPREFIX'] + '/game_title', 'w', encoding='utf-8'
	) as file:
	file.write(title)
	return title

---

I'm not sure if this is the right place for that discussion, but it looks like the database is implemented for umu-protonfixes.
My ideas for alternative implementations would also be implemented here. So I will just post it here.

We should consider if this is really necessary or just an overhead and sometimes even a hindrance.

Rationale:

• It depends on the endpoint being reachable
  • Client internet connection
  • Server availability
• It could be argued that this raises some privacy concerns
• The database and umu-protonfixes must to be in sync
  • The locally installed version of umu-protonfixes will not be updated
  • The remote database will be updated
• We want only entries that have protonfixes associated with them

Other implementations:

• Heroic queries the umu-id via the codename.
• Lutris seems to process the database locally.

Alternatives:

• For umu-protonfixes, we could bundle the CSV. This would keep it private and in sync.

• As I have previously mentioned, I believe we don't need the endpoint or the database:

Sorry if this is a silly question, but do we even need the database in the first place?
We could use the folder structure for the mapping instead.

Example:

gamefixes-egs/a0b8d4482f3d4f939f35f87a3f367865.py -> ../gamefixes-steam/19900.py
gamefixes-egs/25ad72f164b948ab9e05eb18fab2cda8.py

Or even:

gamefixes-egs/a0b8d4482f3d4f939f35f87a3f367865.py -> "../gamefixes/Far Cry 2.py"
gamefixes-steam/19900.py -> "../gamefixes/Far Cry 2.py"
gamefixes-egs/25ad72f164b948ab9e05eb18fab2cda8.py -> "../gamefixes/CYGNI: All Guns Blazing.py"

Not only would this eliminate any telemetry / privacy concerns, it doesn't even require internet access.
On top of that, we'd only have entries for the fixes that were actually used.

[R1kaB3rN]

Yeah, this is probably not the right place to discuss this. Existing clients seem to already query the endpoint or have some file to determine whether a fix exists for the game or not, so there's no need for protonfixes to make a request again.

[R1kaB3rN]

Instead, what we can discuss here is potentially changing the role of the database in protonfixes. I believe there are plans to distribute fixes remotely, so I see the database being helpful toward that end. This would prevent the need of users having to wait for the next GE-Proton or UMU-Proton release just to get a fix for their game.

[Root-Core]

I believe there are plans to distribute fixes remotely

Is this even desirable? My understanding is that Proton is supposed to be "version based". And a fix might be compatible with the latest Proton GE, but not older ones... we saw that with the WMP patches (#111).

If that's true, I don't see the point of the endpoint, and this doesn't fix the out-of-sync issues, or if it does, it's not an argument against unifying the database and umu-protonfixes. The DB is only meant to hold entries that have fixes available here. So keeping the information in multiple places just doesn't make sense.

By the way, is there any information about these plans?

---

Instead, what we can discuss here is potentially changing the role of the database in protonfixes.

We could start by implementing the file structure as suggested earlier, or bundle the CSV as a subproject.
The former could be the first step in replacing the database, if we can get a consensus to do so at some point.

[GloriousEggroll]

the database -IS- needed. It serves as a focal point for all different launchers to pull required data.

the main example is not knowing an UMU_ID. A launcher would query the database with the game title, store, and codename in order to retrieve the ID. Without the UMU_ID they have no way to know to set the ID and that fixes for that ID should be applied.

I agree it likely isn't required here to fetch the title from the website and may be more efficient to include the csv, but the databaase is indeed a huge part of the project.

whether they decide to query the website or package their own copy of the database is all up to them, the point being to have a record of the information provided from the db in order to properly pull UMU_IDs.

[GloriousEggroll]

closing -- I've added umu-database.csv as part of protonfixes and changed the title lookup to use it instead of requiring an internet conneciton:

eea2879