Improving zaparoo integration code

[asturur]

After some good feedback we merged
#2028
That brings zaparoo integrated in the UI, that means you can create nfc tags from your game directly from emulation station menu.

Great.

This was done with keeping compatibility with windows system too, avoiding linux specific code like: batocera-services status

The key issue was knowing when zaparoo is active and well, so that we can enable the menu entries.
We did this pinging a health route on zaparoo web service, but this also requires to hardocode the zaparoo port and to avoid performance disruption we also do this only once and then if for some reason zaparoo was not active you are not going to see the entries untill you reboot.

@nadenislamarre pointed out that the cached status is suboptimal and so is the initial request.

Our goal at zaparoo is to have everyone happy with the code and the feature available, so we would like to improve the current code.

A proposal from @nadenislamarre was to create a /var/run/zaparoo when zaparoo is good and has a reader attached, and batocera check the existance of the file rather than calling /health and caching it.
That would work OK for batocera linux but not for windows retrobat.

I was thinking probably a good compromise would be this:

• the feature needs to be resolved inside the batocera-emulationstation codebase with no ifdef batocera/retrobat
• we stop calling /health
• we stop caching the result of the availability
• we modify zaparoo to make its own http requests with its own user agent that includes the word zaparoo
• in the POST /launch api we check the user agent and if a game is launched with zaparoo user-agent we flag the feature as enabled, so menu entry appear.
• we modify zaparoo ( batocera/retrobat only ) to trigger a call to POST /launch with an empty payload when you connect a reader/writer or at zaparoo boot.

This code should have no impact for who is not using the feature.
if you are a zaparoo user and you want to flash cards/tokens from the UI you can either:

• disable/enable the service from the service menu ( batocera only )
• disconnect/reconnect your reader to trigger the enabling
• flash any card you have handy
• if you don't have any ready card you can still probably use the phone app to trigger a load and that should enable the menu items

Another possibility would be that if there is some config file around we can have a button in the specific zaparoo package UI to change a config file value, users will read that the have to push that button to integrate with the UI properly, and we just switch a value in some ini/cfg file and that's it.

@fabricecaruso @lbrpdx Happy to improve the code if you have pointers.

@wizzomafizzo FYI

[nadenislamarre]

for me the idea is to

• detect if zaparoo is booted / not booted, and cache, mainly if no device to have almost no impact for user having nothing
• limit the intrusion of zaparro, in the code

using a post on /launch is very intrusive.
personnally, i prefer to have a simple file on the fs and if #if batocera, it is less intrusive
and if we change something at boot system, we are less dependant of retrobat.
i don't expect to have a code with no if on 2 différents systems about the boot services
having the same code without #if batocera is not a target to archieve.
the "ideal" version on linux (only) is to use dbus, while it is the way to go on linux only programs. but we don't integrate it while we want to keep the same es software with retrobat (dbus would be too intrusive).

what are the other feedback ? (i've no device, so i've not really used and not really followed ; i may buy one to create an escape game, i will make sure it is compatible with zaparoo to make tests on it)

[asturur]

The main point of improvement was that the way to detect if zaparoo is active is intrusive ( an health check request on game open menu, ONCE ).

Intrusive or not we should clarify if we intend intrusive for the performance or for the code long term health/clarity.
Zaparoo creates its own logs file and has a specific batocera build, so if we want to have ifdef batocera, we can just check a dumb /var/log/zaparoo or whatever, and call it done, but we should also understand how to make the detection for retrobat at that point, it make no sense to break it.

In other prs and in zaparoo one, the usage of different linux and windows code was brought up by @fabricecaruso and to some extent i agree, if detection can be done in the same way by window and linux would be great and easier.

So my proposal was a post on launch, when zaparoo is booted once, zaparoo has its own user-agent and that would let batocera know that zaparoo is around, so if you don't have the hardware/service nothing happens when you open the menu there are no checks to be done. This would work windows and linux.
Zaparoo use the launch post route every time it needs to launch a game, so if the boot check happens out of sync ( zaparoo starting before the webserver starts ) at the first card scan that would be synced anyway.

Can you clarify what you mean by intrusive @nadenislamarre ? What is the aspect of the post request/get request that worries you?

[nadenislamarre]

in batocera, we support many hardware.
when a user has not the hardware, no process nor nothing must be done for this hardware (eventually, for the menu we could allow to check a file)
but for example, it is not allowed to start a process managing zaparoo by default.
we could do a service zaparoo that the user would start, but we prefer to make things working out of the box : when you plug zaparoo (or when already plugged at boot), the udev rule start the process and then it is working.
but es can't try to contact a service that is probably not running.
this is why testing a file (or dbus service) is the simpler to avoid any extra work.