Plugin system for additional stores.

[Renari]

Problem description

No response

Feature description

There are various stores that people would like supported on Heroic, and this list is ever growing. I'm proposing implementing a plugin system for additional stores support.

Alternatives

No response

Additional information

I think this is the best way forward, it would prevent the codebase from becoming bloated with tons of stores that not every user would want.

Relevant issues:

1096

1223

2974

3021

3138

[JakobDev]

Sounds good. How will this work? Do you simple enter th epath to a custom executable that takes the same Arguments and has the same Output like legendary or gogdl?

[Renari]

I was thinking of having a standard interface for plugins and expecting a script to be provided that adheres to that interface, this would this would allow for more flexibility on the plugin authors side since if there is an existing library for that platform they would be able to translate those calls rather than have for fork that library.

[imLinguin]

One idea is to do it similarly to GOG Galaxy with IPC. Like I described here https://gist.github.com/imLinguin/9b570476f7c6a80ab1bf9e14321b35fa

[Renari]

I've found GOG's approach to be extremely error prone after using it for a few years, this would also add complexity since Heroic would have to monitor those processes.

• What do you do if a plugin crashes?
• What if it's repeatedly crashing and how would we determine that?

  Heroic will request list of internal app ids from each plugin and obtain common metadata from external endpoint like https://gamesdb.gog.com/ or custom equivelent.

I think this should be served by the plugin since the closest we have to an all encompassing database is IGDB, but even there they are missing things, something I've encountered frequently when playing games from itch.

[imLinguin]

I've found GOG's approach to be extremely error prone after using it for a few years

I agree it has some issues, but it's up to the plugin to be stable and handle errors gracefully.
I think most issues for GOG's approach happen because plugins are maintained only by community (with few exceptions).

I think this should be served by the plugin since the closest we have to an all encompassing database is IGDB, but even there they are missing things, something I've encountered frequently when playing games from itch.

Centralized database would be required if we wanted to develop capabilities of de-duplicating library entries and having common tags for more advanced filtering. Even if we don't go with that direction idea of this common metadata service is something we kind of need nevertheless.

This is purely an idea and a matter of discussion. Other ideas are welcome

[Renari]

Centralized database would be required if we wanted to develop capabilities of de-duplicating library entries and having common tags for more advanced filtering. Even if we don't go with that direction idea of this common metadata service is something we kind of need nevertheless.

I believe this to be a separate issue, since how would said plugins obtain this id? The store itself wouldn't have references to a central database so it would make sense to do this further up the chain.

[imLinguin]

The plugins wouldn't need that info, Heroic could handle it internally, plugins would only need to care about their service's data

[Renari]

I foresee syncing with a database, at least as part of the plugin system being a massive burden on this being implemented, it seems like it would better be left as an entirely different feature. Since there are lots of edge cases when trying to do that.

The first example that comes to mind is if someone were to make an emulator plugin, they have Final Fantasy III in their library, you identify it as Final Fantasy III, but it turns out it was the NA version of Final Fantasy III which is actually Final Fantasy VI. Now you need features for the user to split entries and manually match them against a database.

[Renari]

@imLinguin I thought about this recently and Plex, Jellyfin etc already do something similar to what you were proposing via plugins that act as metadata providers. This wouldn't work exactly like you describe in your post, you would need to use internal ids instead of gamedb ids and then have a table to map them based on metadata providers. This would cover all cases because if there's a game that's missing metadata it just means a meatadata provider that supports that use-case hasn't been made yet.