Je n’ai pas de le droit de créer un topic dans les « Suggestions pour le core », du coup, je me permet de faire ça à la racine du forum.
Si un administrateur veut bien le déplacer au bon endroit…
Je pense qu’il pourrait être intéressant de supporter différents serveurs pour l’utilisation du Jeedom DIY.
Je pense en particulier :
au serveur web (Apache par défaut), mais il semblerait qu’il n’y ai pas de souci avec Nginx (aucune idée pour les autres).
au serveur de BDD (MySQL ou équivalent par défaut), mais le code utilisant une interface PDO, il devrait être possible d’en utiliser un autre (sans peut-être trop de travail).
Est-ce que cette idée à déjà été envisagée ?
Y’a-t-il une volonté à ce que ce soit possible un jour ?
La réponse est simple trop complexe voir impossible :
nginx oui marche mais faut eviter (vraiment ou alors connaitre parfaitement le code de jeedom), en effet une couche de securité est basé sur les htaccess, passer sur du nginx c’est ouvrir une grosse faille de securité
choisir le type de BDD c’est un travails quasi impossible oui ca tourne peut etre, mais tu perds les backups, la gestion des montés de version de la db, les optiomisations de la db, la surveillance de celle-ci et j’en oublie
Donc pour resumer a ne surtout pas faire et il n’y a aucune volonté d’y arrivé car l’interet est nul… Pourquoi ne pas mettre une bdd mysql ? Pourquoi ne pas mettre apache ?
Pour ce qui est de Nginx, lunarok en tant que développeur semble l’utiliser sans souci (cf le lien du premier topic que j’ai partagé).
C’est justement dans un souci de sécurité que je lui demande la configuration qu’il a mise en place.
Les .htaccess peuvent très bien être transposés dans la configuration de Nginx.
Pour ce qui est du système de base de donnée, sans se lancer dans des débats stériles sur une possible vitesse de lecture, d’écriture ou de mémoire, disons juste que c’est un choix politique.
Je ne suis pas expert du tout de Jeedom.
Les optimisations de BDD, ce sont des index ? de contraintes ?
Ça existe sur tout les SGBD…
Si tous les codes utilisent l’interface PDO, ça devrait simplifier l’harmonisation.
Vous faite que vous voulez mais aussi bien moi que Jeedom SAS on est très clair dessus : ne surtout pas utiliser nginx a moins de transposer a la main les htaccess mais on ne le fera pas et on est pas responsable en cas de faille de securité sur votre jeedom.
Pour la BDD la liste au dessus c’est justement tout ce qui n’est pas par PDO
Je n’ai jamais demandé une quelconque responsabilité de la part de Jeedom.
Je demandais simplement s’il y avait une volonté de laisser le choix des serveurs notamment pour la solution DIY.
Je prends l’exemple de la solution nextCloud que j’utilise sur la même machine, qui supporte Apache et Nginx pour le web, et MySQL/MariaDB, Oracle, PgSQL et SQLite pour les base de données.
Ça me paraissait une jolie idée de laisser les gens libres quand on propose une solution libre, plutôt que d’imposer ses choix… mais ok, si c’est pas le cas.
J’ai déjà commencé un petit peu, vu que ça m’intéresse pour mon installation perso’.
Ça ira peut-être jamais plus loin que mon domicile, mais j’ai un peu de temps à perdre ces jours-ci ^^
Du coup, je vais me transposer mes .htaccess dans mon coin et supprimer les backtick non sql-standard dans les requêtes
Bon… sans y avoir passer des heures, j’arrive à avoir un dashboard plutôt fonctionnel…
J’ai aucun plugin faut dire, donc c’est pas très difficile non plus
Les 80% du taf tiennent en quelques str_replace, les backtick (`) et les mots réservés à échapper (table « user », colonnes « id », « order », « timestamp », etc…).
Les 20% restants sont les quelques rares requêtes que j’ai été obligé de ré-écrire, comme les REPLACE config, et autre ORDER BY FIELD().
Mais dans l’ensemble, c’est pas insurmontable.
J’ai bien compris qu’il n’y avait pas de volonté de proposer une ouverture à d’autres SGBD, mais à minima, ça vous intéresse si je push sur votre GIT les requêtes que j’ai ré-écrite dans un format SQL « standard » ?
Je veux dire, ça coute rien de faire un « ON DUPLICATE KEY » au lieu du « REPLACE » spécifique à MySQL, et un « CASE » pour le « ORDER BY FIELD », ça respect (presque) les standards et ça sauve des chatons.
Si ça n’intéresse pas, je garde mon fork dans mon coin.
J’aimerais te dire oui mais j’ai pas le temps de faire des tests complets pour valider qu’il n’y ait pas de régression et vu les coup que je me prend a chaque soucis j’aurais pas le courage de monter au créneaux pour défendre cela en cas de bug.
