gamelib URI format

[karolherbst]

as discussed with Kejiro from fireflower gamelib should provide an URI scheme, so that stores can add links for gamelib integration on their website.

We should discuss how such a scheme should look like.

$store_id The storeid is taken from the store configuration file. We will set the key equal to the name (with some formatting like " " replaced with ""), but will remain the same for ever.

$game_id The game_id should be equal to the id used by the store_backend (usually the external id handled by the store itself).

gamelib://$store_id/$game_id/install used to install games. gamelib://$store_id/$game_id/launch used to launch a game. It will ask the user to install the game if not already done.

Both will ask the user to add their account to gamelib if not present. Store configuration files should be added to a public repository first. The auto download apporach from store pages might not be feasible, because it will require either another URI or a special place, where configuration files might be searched.

[Cheeseness]

So far as our functionality goes, these might be helpful gamelib://$store_id/$game_id/verify gamelib://$store_id/$game_id/update gamelib://$store_id/$game_id/uninstall

Would we also handle parameters to be passed to the client and/or game?

[karolherbst]

I don't see a reasonable use case, where a store page want to advertise gamelib://$store_id/$game_id/verify. The same for gamelib://$store_id/$game_id/uninstall. A store usually don't know what was installed in gamelib, so they can't react to information only provided after installation of games. That means, thet even gamelib://$store_id/$game_id/update might be hard to handle. But I think we should create the same interface for install and update, because they don't differ much internally.

[karolherbst]

Though these commands might be useable through a xdg-open approach. We could, instead of using strange command line args, have a URI cli interface to handle common use cases. In this scenario I could also imagine of something like gamelib://games/list/installed or gamelib://games/updateAndVerifyAll

[Cheeseness]

Yeah, these would be mapping to client functions specifically (that the client then uses to perform an action that the user might normally trigger using the client GUI) rather than store provided services.

[karolherbst]

Yeah, I think we should implement the URI handler in gamelib, so that client only needs to capture them through MIME handlers and just pass them like gamelib.handleURICall(string)

[karolherbst]

Did I just create a one function only URI API for clients to call gamelib functionality?

[karolherbst]

24

[Jookia]

I don't think using the URI as an API would be a good idea, mainly because it'd introduce having to parse everything for a result instead of just returning structs, duplicating work.

[karolherbst]

Then how should stores trigger game installation from their websites in the GUI? I am sure we need an URI scheme anyway. Maybe it shouldn't be as big as the "real" API, but at least we need a little one.

[Jookia]

I mean as in the gamelib API, not the client API.

[karolherbst]

I would like to have a way how applications can trigger actions in gamelib. Maybe we want to add game invites into gamelib later, so somebody would write a link to you (maybe over pidgin) like gamelib://invite/$ip/$port/$store_id/$game_id/

[Jookia]

It doesn't make sense to me that libgamelib, rather than the client, be addressed by the URI, as the client is what would be affected the by the URI. Then the client could parse the URI and turn it in to its own events, of sorts.

[karolherbst]

@kejiro what do you think about that?

[karolherbst]

Anyway the client needs to register all URI handlers, because gk will run in the client process anyway. At least on Linux you need to declare stuff in a *.desktop file and it will be called to the client. On the other hand, we control the main() function so stuff is directly in our control. We have still the possibility to pass unknown stuff to the client via a client::GameKeeperUI.handleURI() method.

I am not sure how URI stuff is handled on Mac OS X and Windows though.