[WIP] Recalbox Manager

[DjLeChuck]

@subs Haaa je comprends plus rien... XD Tu ne veux plus que j'utilise l'API et que je fasse directement des modifs dans le recalbox.conf de share_init ?

[Substring]

@DjLeChuck non pas du tout. Tu utilises l'API sans pb, mais ton interface tu la termines pour qu'elle puisse gérer tout recalbox Et surtout :

• le reboot/shutdown
• le script de support
• un bouton "kill running emulator" genre "panic mode" pour éviter que les gens rebootent leur recalbox et couinent qu'elle est cassée
• je ne sais pas quoi encore

NodeJS ou django, à ton aise

[DjLeChuck]

@subs Ha ! Oui ça c'est bon. Je gère déjà le reboot / shutdown (puisque l'API le propose).
Le script de support faudra que je vois comment ça marche.
Pour le kill running emulator et autres je verrais pour faire une PR sur l'API pour ajouter cette fonctionnalité d'abord. Sauf si on part du principe que mon manager s’intégrera dans recalbox directement ce qui me permettra de faire des appels systèmes tranquillement (ou alors qu'une des possibilités de l'API est d'exécuter une commande système et de renvoyer le résultat...)
Mais comme je suis en train de voir pour basculer sur du Node plutôt que du PHP je vais devoir reprendre ce que j'ai déjà...

[Substring]

@DjLeChuck si ton truc est abouti et viable, oui on peut l'intégrer. Le manager dans son état actuel risque fort de prendre la poussière ...

Pour le kill des emulateurs, on a déjà un embryon sur un autre topic en python, mais rien de difficile, si ce n'est que l'utilisation de python est pratique par rapport à configgen (qui a entre autre quasi tous les les binaires des émuls de listés)

[DjLeChuck]

@subs Ok donc raison de plus pour le passer en Node afin de pas s'embêter à avoir PHP encore en plus sur recalbox...

Si tu retrouves le topic je suis preneur dans ce cas, sinon je le chercherais dans tous les cas le moment venu !

[Substring]

@DjLeChuck regarde ces 2 liens :
https://forum.recalbox.com/topic/3504/emulator-exit-button-gpio/11
https://forum.recalbox.com/topic/3435/game-reset/10

le 1er est celui que tu cherches. Le 2e est juste un petit coup de génie sur comment faire le reset d'un jeu sans HK avec un buoton GPIO (mais la techinique uilisée derrière n'a pas besoin de GPIO)

[neolao]

Je me replonge dessus petit à petit chaque jour.

Le plus gros changement sera celui de subs. Une partie de l'API sera donc totalement dépendant de recalbox.conf

Le reste sera des alias ou des choses supplémentaires qui ne touchent pas à la config.

J'ai une réflexion sur les URLs des endpoints à choisir seulement.

[DjLeChuck]

@subs Merci pour les liens
@neolao Si jamais tu as besoin d'un coup de main ne serait-ce que pour la réflexion hésites pas à demander par MP par exemple.

[Substring]

@neolao comme je l'ai dit plus haut : ton api elle s'en fout du recalbox.conf, c'est l'IHM derrière qui doit gérer ca proprement. Enfin personnellement, je pense que ce n'est pas à tno API de vérifier si les valuers données sont bonnes ou non. Elles doivent t'êtres données au bon format, tu ne devrais pas avoir à te poser de questions sur leur validité

[DjLeChuck]

@subs Heuu là je suis pas d'accord... Certes de mon côté le manager doit envoyer une valeur correcte mais je ne suis qu'un client de l'API. Le côté serveur c'est justement l'API donc il FAUT une validation côté serveur ce n'est pas sécurisé sinon et n'importe qui peut envoyer ce qu'il veut comme donnée et réaliser des injections.

Après ça c'est dans la pratique habituelle des choses. Ici comme tu l'as déjà répété le système n'est pas ouvert etc. mais bon tu peux te faire pénétrer ton réseau et voilà...

[Substring]

@DjLeChuck mais c'est déjà le cas ! tu peux envoyer ce que tu veux je parie comme valeur à l'API

[neolao]

J'ai oublié si on peut pour tout type de propriété.

En tout cas, je confirme que c'est à l'API de gérer les bonnes valeurs.
Il pourra même servir les valeurs possibles, ce sont des ressources en GET finalement aussi.

[neolao]

Et potentiellement, comme le frontend a ses traductions pour les noms de propriétés, valeurs et descriptions, l'API peut exposer les traductions aussi.

Un manager web serait comme un frontend à recalbox.

Idéalement, le frontend en sortie vidéo devrait être découplé du backend via une API. Ce qui permettrait d'en changer.
Dans mes ambitions, je voulais allez loin et l'API est la première pierre.

[DjLeChuck]

@subs J'ai pas compris ta réponse ^^' Oui on peut envoyer ce qu'on veut à l'API sans qu'elle ne dise rien et ce n'est pas normal. Elle devrait contrôler les données reçues.

@neolao Pour les valeurs possibles elle pourrait oui, mais ce n'est pas une obligation car c'est à ça que sert une doc aussi, indiquer ce qui est possible de faire ou non, et on en est pas encore là De même pour les traductions elle pourraient être données dans l'API mais ce n'est pas non plus une obligation. L'API peut très bien rester "bas niveau" et ne donner que les valeurs bruts ce n'est pas déconnant.

[neolao]

Bien sûr, je parlais de ressources supplémentaires qu'elle pourrait fournir.

Imagine pour paramétrer la résolution de l'écran qu'une ressource te donne les valeurs possibles par rapport à un diagnostique.

Je vais peut-être faire une différence d'URI pour modifier la configuration et les autres actions. Par exemple, changer le volume, il y a une différence entre modifier la config et modifier le volume courant.
Actuellement, le endpoint est /audio/volume.

Je ferai peut-être un /config/audio.volume pour être dans le schéma /config/{property}.

[Substring]

Je vous explique pourquoi l'API est mal barrée pour faire du contrôle d'intégrité sur ce qu'on lui passe :

• je mets un mode video non supporté par le moniteur, mais formellement correct
• je spécifie un core d'émulateur qui n'existe pas (parce que, faut etre honnête, les cores par console ne seront pas listés dans le recalbox.conf, ils sont déjà dans le es_systems.cfg)
• j'indique un mauvais systeme
• je mets un ratio inexistant (il y en a 3 ou 4 dans la 4.0, plus d'une vingtaine en 4.1)
• il faut balayer les zones libres sans controle (user/pass retroachievements par exemple)
• je spécifie un configfile qui n'existe pas

Bien sûr tous ces cas peuvent être "résolus" mais à quel prix ...

[neolao]

Pour moi, ce sont de mauvaises raisons.
L'API doit avancer au même rythme que les fonctionnalités.

Mais en pratique, ce n'est pas un projet basé sur l'API, ce dernier va avancer avec un autre rythme.
Donc, c'est plus sûr de ne pas contrôler l'intégrité de la valeur.
Par contre, ajouter une ressource qui donne les valeurs possibles, c'est intéressant pour un consommateur de l'API. Au pire, les valeurs ne seront plus bonnes mais il pourra toujours envoyer ce qu'il veut.

[Substring]

Je peux te donner la réponse à chaque question que je t'ai posée au-dessus quasiment. Mais toutes les réponses ne seront pas dans le recalbox.conf, ou talors ca veut dire reporter des valeurs d'autres fichiers dans le recalbox.conf. C'est suicidaire pour la maintenance.

Au final, tu te rabats bien sur "l'API fera son boulot quelle que soit la valeur qu'on lui passe" puisque tu reportes les valeurs un cran au-dessus, et donc l'IHM

[neolao]

Tout n'a pas besoin d'être dans recalbox.conf évidemment.
On peut lire d'autres fichiers bien sûr.

Il est possible tout de même de contrôler au moins l'intégrité des propriétés :

• booléenne
• nombre dans un interval
• choix dans une liste finie (et donc rajouter les nouvelles valeurs quand il faut)

Le reste est un développement supplémentaire qui pourrait dépendre d'autres fichiers comme es_systems.cfg. Et donc si ça évolue, l'API s'adaptera automatiquement.

Le mode video vient de la réponse à tvservice.

Bref, on peut tendre vers ça petit à petit. L'intégrité n'a pas besoin d'être absolue.

[DjLeChuck]

Mon pauvre sujet devient n'importe quoi Il n'y a pas un endroit où on pourrait débattre de tout ça qui soit fait pour (je demande hein, m'en fiche que mon topic serve à ça :P) ?