[WIP] Recalbox Manager
-
@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. -
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.volumepour être dans le schéma/config/{property}. -
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 ...
-
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. -
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
-
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.
-
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) ? -
Salut
on peut splitter le sujet , un modérateur qui suit le débat le fera -
Hello,
Des nouvelles du front.
Je n'ai pas du tout avancé sur la partie visible de l'iceberg car je cherchais une autre techno que PHP afin de rendre l'outils utilisable plus facilement pour tous.Puis, @subs m'a dit qu'il pourrait finir directement sur recalbox afin de remplacer l'existant alors je me suis dit que j'allais partir sur un serveur nodejs, puis après avoir testé j'ai pas aimé, donc je me suis dis pourquoi un serveur en Go, puis j'ai testé et j'ai pas aimé, donc je pars au final sur du Django comme c'est le cas pour le manager actuel comme ça je sais que ça tournera sans problème.
Du coup, je dois en revenir là où je m'étais arrêté avec la version PHP afin de pouvoir vous montrer plus de choses...
-
@DjLeChuck erf c'est con parce que si c'était en JS j'aurais pu aidé un peu
-
Sinon en gardant un node qui sert une page, vous faites une Single Page App en React.
-
-
En servant juste des fichiers statiques, ton empreinte mémoire sera plus bas pour la machine.
-
Hello,
Bravo pour ce projet, en parcourant rapidement les possibilités de l'API (même si je ne comprend pas tout
) je vois qu'il y a plein de possibilités et du coup autant de réglages qu'on aura plus a faire en ligne de commande ou en modifiant des fichiers de config.J'imagine déjà, quand l'API évoluera, un 2ème petit écran avec en fonction du système choisi une image avec le mappage des touches ou un joli screenshot du jeu en cours ...
J'en salive d'avance, et bon courage.
-
@DjLeChuck ca va ? On n'a plus de news
-
@subs Pfiouuuu ouais ça va, c'est la galère en moment niveau temps dispo pour avancer sur le manager. Je m'y remets ce soir, coûte que coûte, surtout que je n'avance pas bcp à force de changer de techno...
@ouaich Merci pour les encouragements
-
@MikaXII vaut mieux nodejs ou django pour étendre les fonctionnalités du manager ?
@DjLeChuck si à l'occasion tu uppes ca sur un repo, fais signe
-
@subs J'ai laissé tomber l'idée de Django à cause de vous
Là je suis sur du React.
J'ai un repo en local pour le moment. Je le mettrais sur mon GitHub ce soir si j'y pense ^^ -
Tu fais un React + Redux avec router j'espère.
On aimerait donner un lien à quelqu'un et que ça amène direct au bon endroit. -
@neolao Oui pour le router, non pour Redux. Je ne me suis pas penché dessus et donc je ne sais pas en quoi il peut m'être utile ?
