Salut tout le monde,
Beau travail @pierre-gilles.
Petite question, si j’ai bien compris maintenant nous n’avons plus de store pour les modules/services. Tous les services seront donc dans le core de Gladys et chargés au démarrage ?
Je commencerai dès que possible la migration du service CalDAV vers Gladys v4.
C’est un des avantages du décalage horaire, quand vous dormez moi je bosse 
Top! Après pour ça pas besoin de l’API REST, tu le fais en interne.
Complètement 
Je pense que ce topic est très bien, si tu veux bosser sur un sujet, tu peux en parler ici! Ensuite dès que tu commences à bosser dessus, le plus tôt tu créé une PR le mieux c’est (tu peux indiquer sur GitHub que cette PR est en cours)
Effectivement ce service est crucial. C’est d’ailleurs un bon exemple pour moi de service qui sera en 2 versions:
La priorité va au service en interne, pour l’instant l’API MQTT pour les services distants n’est pas encore 100% prête.
Tout à fait ! C’est l’objectif de cette v4, apporter une expérience consistante et un produit complet qu’on maitrise de bout en bout.
Le service CalDAV est intéressant, pour l’instant je n’ai pas encore fait de service de calendrier dans Gladys 4 donc il y aura une petite partie réflexion avant le développement.
Je pense ça vaut le coup qu’on réfléchisse ensemble à tout ça N’hésite pas si tu as des questions, ou même s’appeler, je suis dispo!
Salut, je reste un peu sceptique sur la partie disparition du store de modules.
Tous les anciens modules vont devenir des nouveaux services sur le repo de la v4 ??? Où seuls les services permettant d’avoir un nouveau protocole ?
Je ne souhaite pas être obligé de charger 1000 services pour un seul qui m’intéresse.
J’ai du louper un bout …
Yes Je veux que Gladys soit un produit consistent, clé en main et qui fonctionne dès le début sans avoir à triffouiller comme c’est le cas aujourd’hui.
(Attention, il n’y aura pas de service redondant, on aura un seul service bluetooth, un seul service Philips hue, etc…)
Avec des modules séparé actuellement, ça créé des tonnes de problèmes. Quand tu installe un module Gladys 3, Gladys fait un git clone + NPM install + reboot de Gladys. Et on ne parle même pas d’intégrer le module dans UI, ça n’a jamais marché correctement dans Gladys 3 et on a du faire des hacks affreux pour que ça marche plus ou moins… Quand je vois le nombre de messages du forum où certains ont une UI qui a sauté à cause de l’installation d’un module, c’est pas normal que ce soit possible!
Tout ce qui est fait côté utilisateur actuellement à l’installation d’un module ne devrait être fait que côté développeur.
Après je pense que tu surestime la taille d’un service… Un service c’est quelques fichiers JS en général, on parle de quelques kilo octets de code… Je ne vois pas en quoi ça alourdit Gladys
En fait je pense qu’il vaut voir Gladys 4 d’une façon différente de Gladys 3, ce n’est pas le même produit.
Dans Gladys 3, j’ai naïvement pensé que mon rôle en crééant Gladys c’était de créer la plateforme, mais de laisser « l’expérience module » séparée du core.
Mais ce que j’avais sous-estimé, c’est que ce que va retenir un utilisateur sur Gladys, c’est l’expérience globale qu’il a eu. Si il installe Gladys, qu’il installe le module speak, et que Gladys crash. (et on y peut rien, « npm install » ça rate souvent pour des raisons externes type manque de ram, downtime NPM), son feedback ça sera: Gladys ça ne marche pas et c’est instable.
Mon paradigme pour Gladys 4, c’est que les services font partie intégrante du produit, ce n’est pas des détails: c’est le coeur de l’expérience de Gladys.
Je veux pour que l’utilisateur, utiliser le bluetooth ça soit juste cocher la case « bluetooth » dans l’interface, rien de plus.
Et pour ça, ça demande d’avoir les services au coeur du produit, avec la même rigueur de développement que le core de Gladys:
C’est la seule façon d’avoir une expérience globale qu’on est capable de maitriser de bout en bout
N’hésite pas si tu as des questions/remise en question sur tout ça, c’est une partie que j’ai longuement réfléchi et je ne t’ai mis que les grands axes ici. On pourra aussi en parler de vive voix à l’appel communauté de dimanche!
Dans le pire des cas, on créera un service pour charger des “plugins” 
Mais je comprends l’idée, soit on a une solution ouverte, voire trop ouverte (v3) soit une solution stable et maîtrisée, soumise à la validation constante de l’équipe principale (toi), la v4.
Le seul truc dont j’ai peur, c’est qui si une demande de nouveauté est faite, elle prenne trop de temps à être intégrée.
Aha ça serait revenir aux problèmes de la v3 
Exactement! Après je pense que tu es inquiet par rapport à mon rythme de merge GitHub, j’y ai réfléchi et je pense que ça va être assez différent de la v3.
Sur la v3:
Sur la v4:
Il y aura beaucoup de temps gagné là dessus.En fait le fait d’avoir tout dans un mono-repo ça change beaucoup de chose.
Salut @pierre-gilles,
super travail ça avance bien de ce que je vois 
!
j’ai quelques question :
Il y a quelques modules maintenant et je pense que ça va faire pas mal de taff…
Ensuite j’avoue partager l’inquiétude de @AlexTrovato concernant les services interne.
Si par exemple quelqu’un veut un service TV phillips (par hasard [https://community.gladysassistant.com/t/recherche-module-philips-tv/4667/5]), il devra attendre que cela soit fait et déployé ?
C’est un dire que je ne pourrais pas dev un service dont j’ai pas le materiel et le faire tester a un membre comme j’avais fait avec @Jean34 et la TV Viera avant de le déployer en prod ?
il me semblait avoir compris précédemment que certain module deviendrait des services mais pas tous, a moins que je me trompe 
Petite suggestion:
Faudrait pas plutôt un gros service TV qui viendrait intégrer au fur et à mesure des modèles ?
Mais je suis d’accord avec toi, ça va être un peu plus chaud pour diffuser un truc à des testeurs…
J’imagine pas la galère que ça aurait été avec @piznel et son module Xiaomi s’il avait fallut toucher au « core » sans arrêt…
Pas encore! Pour l’instant mon focus c’est vraiment d’avoir Gladys core + services le plus avancé possible, pour pouvoir sortir une alpha au plus vite
Je dirais que je compte sur chaque développeur de module v3 pour aider à migrer leur module sur Gladys 4, avec mon aide bien entendu. Après le plus important dans un premier temps c’est déjà d’avoir les services « essentielles » (Z-wave, Philips hue, Milight, Bluetooth, Xiaomi, etc…), les autres services arriveront au fur et à mesure en fonction des disponibilités de chacun!
Après, je viens de regarder et sur le store de module v3 on a 54 modules publiés. Rien de méchant à migrer!
Rien ne t’empêche d’envoyer une version bêta de Gladys à un autre utilisateur. Pour rappel, l’installation de Gladys 4 est radicalement différente, c’est juste un pull d’une image Docker, donc rien n’empêche d’avoir dans l’UI de mise à jour une option avancée pour mettre à jour Gladys via image « preview ».
En fait dans Gladys 4 il faut voir Gladys comme un produit complet. Quand tu envoyais juste un module à tester à utilisateur, il n’avait pas forcément la même version de Gladys que toi, si toi tu attendais une PR qui était en attente sur le core, tu étais bloqué. Là Gladys c’est un tout, donc à priori si tu lui envoie une image toute prête, tout marchera comme chez toi.
Oui!
C’est déjà le cas!
Chaque page de configuration d’une marque de périphérique à un tutoriel riche qui explique comment configurer le périphérique. J’incite chaque contributeur Gladys a construire des UI riches et complète pour les intégrations
Exemple:
Je pense qu’on va trouver des solutions pour le développement Moi au contraire le souvenir que j’ai des process de développements de modules Gladys 3 c’est plutôt que c’était horrible ^^
Si tu te promène sur le sujet « Zwave », « Snips » ou « Rpi infos », tu as à la pelle des problèmes d’UIs qui sautent, ou des bugs tout bête qui devrait jamais arriver à l’utilisateur final, et qui sont uniquement dû à des problèmes de process de développement.
Je suis d’accord qu’on va perdre un peu en agilité, mais on va gagner énormément en fiabilité du produit et en sécurité. C’est qui manque actuellement à Gladys pour convertir des utilisateurs qui cherchent une solution domotique sérieuse.
Et par rapport à ça, ne pourrait-on pas laisser un espace comme la v3, pour charger un module depuis un repo externe ? Ce qui permettrait de faciliter le test d’un module avant qu’il soit intégré au core ?
Pas vraiment, l’image Gladys de production sera une image buildée très différente de ton installation de développement. Pour être la plus minimal possible, elle sera livrée sans aucuns build tools.
Et même, ça ne ferait pas de sens, je le répète: il n’y a plus de notion de modules, les services sont dans le core! C’est un seul et même logiciel.
Developper un service, mon premier avis :
Bonjour, j’ai passé mon week-end à développer (je ne dis pas migrer) un service de prise en charge du Bluetooth.
La vision est désormais bien différente, car il est clairement nécessaire de développer 2 parties, le front et le back.
Le front : preact c’est magique, les outils de développeur fournis avec aussi. Tu changes une page, tu sauvegarde, ton navigateur se rafraîchit et tu vois directement le résultat… c’est un réel plaisir. Et preact est tellement plaisant à coder. Mais c’est assez complexe de s’intégrer à l’existant, et les risques de conflits git entre les différents modules vont êtres considérables.
Le back : on reste assez proche de l’ancien système modulaire, service qui reste assez indépendant niveau code.
Gros avantages sur le fait d’avoir séparé le front du back, tu peux vraiment développer l’un sans l’autre avec les URL mockées, mais la phase d’intégration n’est pas neutre non plus.
Par contre on est clairement sur une version actuellement en cours de dev, non finalisée, donc je pense qu’il est important que chacun puisse noter les points encore non couverts afin de ne rien oublier.
Et j’avoue que le rendu final une fois l’intégration terminée est vraiment sympa.
Je pense déjà à un système de sous modules de services, modules de devices. Mais il sera très difficile de ne pas développer dans le repo v4.
Petite remarque, je trouve ça quand même assez fâcheux de charger les librairies zwave, philips-hue et autres, alors que je n’utiliserai pas ces services.
A + pour la suite.
Bonjour @pierre-gilles, je viens de regarder l’appel que tu as faits sur YouTube pour ce mois.
J’ai pensé à un truc pour l’onglet “intégrations”
Lorsque l’utilisateur clique sur “intégrations”, il retrouve tous les modules qu’il a installé.
Cela fait rajouter une page mais ça sera plus claire pour l’utilisateur.
Ensuite dessous les listes des devices, communication, calendrier et autres que je vois comme une liste de possibilités.
On pourrais l’appeler “Store” un jour il y aura peut être des modules payant.
Y’a plus de modules dans la V4
Si Gladys se transforme en jeedom ça va pas le faire. Je crois pas que c’est la philosophie du projet.
Salut à tous!
J’ai eu une question pertinente hier lors de l’appel communauté: A quelle date va sortir Gladys 4 ?
Jusque-là, j’évitais de fixer une date car il était difficile de quantifier les développements étant encore en phase de “recherche” et d’exploration, et je ne voulais pas gâcher le produit en fixant une date beaucoup trop ambitieuse (ou au contraire prendre mon temps en fixant une date trop éloignée). Et surtout je sais d’expérience que si j’annonce une date, je risquais de décevoir si la date n’est pas atteinte. Mais aujourd’hui, maintenant que le premier milestone backend a été atteint, les étapes restantes sont assez claires et il est possible de se fixer un objectif de sortie! Ca permet de se donner un objectif commun et d’éviter que les développement ne traînent.
Voilà la roadmap que je vous propose:
J’ai tablé sur 1 mois pour migrer les services de Gladys 3 vers Gladys 4.
Je ne parle pas de tous les services, à minima les services essentielles:
Devices
Total: 12
Communication
Total: 3
Calendar
Weather
Total: 1
Navigation
Total: 1
Cette roadmap nous emmène à un feature freeze le dimanche 23 Juin, pour une première alpha release le mercredi 26 Juin.
Qu’en pensez-vous? 
Je vais créer toutes les tâches et tous les milestones dans GitHub pour qu’on puisse avoir une vision de l’avancement et qu’on puisse repartir les tâches et voir où chacun en est.
Les issues/PR GitHub seront la principale plateforme de communication pour ce développement.
Exactement!
Content que tu ai aimé toi aussi le confort de dev qu’offre preact! Pour les conflits git, pour moi Gladys ce n’est qu’un seul et même produit donc après c’est du développement git de manière général, si on fait ça proprement il n’y a pas de problèmes
100% ! Ce n’est pas terminé, comme je disais on n’est seulement au milestone backend v0.1
Ce ne sera plus le cas dans la version finale, il faut que je ne charge ces libs qu’au start du service et que si l’utilisateur les a configuré. Bonne remarque.
Ni l’un, ni l’autre. Gladys 4 est un produit unique, il n’y a plus de séparation.
Salut,
tout dépend de la disponibilité et du nombre de développeurs.
Moi, à partir de fin mai, jusque début juillet, j’aurai beaucoup moins de temps disponible.
PS (hors sujet) : pour le module Bluetooth, je compte mettre en place un système de “distance des nodes” comme tu proposes pour ZWave, il sera intéressant de modulariser cette partie, histoire de rester iso affichage.
Pour ça je vais créer toutes les issues GitHub (une par module à migrer, une par feature restantes du core) et chacun pourra indiquer si il veut aider sur certaines issues. Les issues/migrations de modules où personne ne se manifeste je le ferais.
Perso je passes mes journées là dessus, donc je pense qu’en 2 mois j’ai largement le temps de m’occuper de beaucoup de sujets restants!
Mm ok je vais créer l’issue du module Bluetooth, on en parlera dessus!
