Ce n'est pas un clone de Redis, et ça n'a pas la vocation de faire exactement ses tâches (autant l'utiliser lui directement).
Il n'y a pas aujourd'hui dans Robert, la possibilité de faire des réseaux interprocessus, où chacun serait soit un maître, soit un esclave (même pourquoi pas à l'avenir avec les fonctions de souscription, j'y ai pensé).
Sur la gestion des valeurs stockées, une base avec des centaines voire des milliers de hashmap et des fonctions de souscription, ça représente vite un projet qui nécessite de se pencher très, très sérieusement sur la gestion des données périmées effectivement, au niveau logique et de l'implémentation précisément. Une fuite de mémoire peut être un catastrophe rapide et sans aller jusque là, c'est juste pénible à suivre en terme de programmation.
Rust a choisi dans son fonctionnement, de se pencher sur les durées de vie et c'est tout l'intérêt d'avoir un garbage collector statique, qui est par nature bien plus sûr que du C et équivalent (de mémoire Redis est en C), tout en offrant des performances plus intéressantes qu'un langage interprété.
Sur la définition d'un délai d'expiration, ce n'est pas propre à un outil ou le choix d'un langage pour moi, mais un attribut d'une implémentation ou d'un usage. Sur Robert, la mise en œuvre me paraît facile : une boucle qui parcourt à un rythme régulier le stockage et lors d'un accès à une valeur, confirmer que son délai est toujours actif. La gestion des accès concurrentiels est réglé via Arc+Mutex, pour tous les canaux.
J'espère avoir répondu à l'interrogation…
Au-delà, sur le choix de Rust, à la différence d'un projet qui aurait été en Java par exemple, il n'y a pas besoin d'avoir une plateforme logicielle sous-jacente lourde. L'emprise mémoire pour la gestion de Robert est très faible. De plus Rust a un niveau de finesse et robustesse natif (refus de compilation sinon), qui est un gage de qualité supplémentaire.
Initiative louable. Pour ma part, j'ai pris le contre-pied avec une logique de flux par poste/navigateur par le biais d’un module (dans les nouveautés : directement en WebExtension).
Quelques remarques sur les sources de SERGE :
les sources sont un peu en bazar (je suis mal placé pour en parler mais tant pis). Exemple : "databaseConnection" est dans "handshake" ? Pourquoi ? Ce ne serait pas plus simple d'avoir un module pour toute la gestion de BDD (par exemple insertSQL) ? Et que le module ne soit qu'une interface entre une BDD au choix et non MySQL ? Voir SQLAlchemy.
Le choix de SQL est judicieux pour un nombre "peu élevé" (à l'échelle d'une machine s'entend…) de données : pour des comptes utilisateurs, les flux RSS, etc. J'ai un doute par contre pour le choix du contenu des flux lui-même, qui n'a pas besoin des contraintes ACID : SQL est moins performant que noSQL. De plus SQL n'est pas scalable : une montée en charge impose de faire grossir un seul serveur, ce qui n'est plus dans la logique des orientations de SI. Notamment pour des professionnels.
Je n'ai rien vu d'handicapant pour le passage de Python2 à Python3, sinon que vous restez sur une logique synchro. Vu que vous allez bosser sur un même serveur, une logique asynchrone semble plus adapté pour le coeur pythonnique.
Pour le reste, le choix d'un IU par PHP est justifié mais il reste des choses assez étonnantes :
-- des fichiers erreurs individuellement codés à la main ??!! -> gestion par le HTaccess et redirection vers une page générique qui prend en charge l'erreur qui, par ailleurs, ne semble pas remonter au niveau admin -> pas de suivi des défauts ??!!
-- aucune utilisation rationnelle des templates : plein de pages PHP pas utiles.
-- pas de possibilité d'utiliser PHP pour contrôler les scripts Python ?! C'est mal -> à modifier d'urgence !
Sur le choix du Wiki : j'aime bien Dokuwiki dont la base est "flat". Rejoint ma remarque sur SQL/noSQL.
… Ainsi il me semble modestement :
la logique d'ensemble est mal foutue : il faut un outil scallable, qui est en Python et reçoit des commandes de partout, y compris de pair (de serveurs comme lui). Les commandes validées (question de sécurité) en local et générée par PHP à la demande de l'utilisateur, par le biais du serveur Web (ou alors en interne de Python avec CGI), pour gérer l'ensemble des flux sans passer par la BDD, ce qui soulage le moteur de BDD et le renvoi à sa condition de gérer des données par de la configuration.
A défaut de passer en asynchrone pour Python, des tâches CRON sont peut-être plus adaptée pour des flux RSS avec un verrou pour éviter la double lecture simultanée,
rationnaliser les fichiers de configuration : le changement de mots de passe de BDD dans votre situation est par exemple, problématique…
question des sauvegardes, des insertions d'anciennes sauvegardes : pas gérées ?! Quid des défauts et des relances de tâches (cf daemonisation).
Enfin si vraiment vous voulez du simple : serveur en Python avec des API (bien documentée et bien pensée) en REST pour donner des ordres. CURL ou WGET pour les appels, par le biais de CRON, sur le système hôte. PHP pourra ainsi dialoguer avec le coeur de Serge avec un simple "include". Vous diviserez par deux vos problèmes et la taille du code !
Et si vraiment l'interprocessus devient impératif face à la montée en charge, toujours dans la logique d'API : XML-RPC + un verrou entre deux serveurs.
Pour les autorisations: les JSON Web Tokens sont vos amis pour la vie.
[^] # Re: Mes deux centimes de vieux francs
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Ce n'est pas un clone de Redis, et ça n'a pas la vocation de faire exactement ses tâches (autant l'utiliser lui directement).
Il n'y a pas aujourd'hui dans Robert, la possibilité de faire des réseaux interprocessus, où chacun serait soit un maître, soit un esclave (même pourquoi pas à l'avenir avec les fonctions de souscription, j'y ai pensé).
Sur la gestion des valeurs stockées, une base avec des centaines voire des milliers de hashmap et des fonctions de souscription, ça représente vite un projet qui nécessite de se pencher très, très sérieusement sur la gestion des données périmées effectivement, au niveau logique et de l'implémentation précisément. Une fuite de mémoire peut être un catastrophe rapide et sans aller jusque là, c'est juste pénible à suivre en terme de programmation.
Rust a choisi dans son fonctionnement, de se pencher sur les durées de vie et c'est tout l'intérêt d'avoir un garbage collector statique, qui est par nature bien plus sûr que du C et équivalent (de mémoire Redis est en C), tout en offrant des performances plus intéressantes qu'un langage interprété.
Sur la définition d'un délai d'expiration, ce n'est pas propre à un outil ou le choix d'un langage pour moi, mais un attribut d'une implémentation ou d'un usage. Sur Robert, la mise en œuvre me paraît facile : une boucle qui parcourt à un rythme régulier le stockage et lors d'un accès à une valeur, confirmer que son délai est toujours actif. La gestion des accès concurrentiels est réglé via Arc+Mutex, pour tous les canaux.
J'espère avoir répondu à l'interrogation…
Au-delà, sur le choix de Rust, à la différence d'un projet qui aurait été en Java par exemple, il n'y a pas besoin d'avoir une plateforme logicielle sous-jacente lourde. L'emprise mémoire pour la gestion de Robert est très faible. De plus Rust a un niveau de finesse et robustesse natif (refus de compilation sinon), qui est un gage de qualité supplémentaire.
[^] # Re: Après weBOOB voici ROBERT !
Posté par JulienG . En réponse au message Robert, un logiciel de stockage en RAM . Évalué à 3. Dernière modification le 20 avril 2020 à 09:21.
C'est fait ! (quelques corrections mineures de style et l'ajout d'un lien).
Merci beaucoup d'avoir pris le temps de la lecture et de la transformation en dépêche.
Bonne journée à toi.
[^] # Re: Après weBOOB voici ROBERT !
Posté par JulienG . En réponse au message Robert, un logiciel de stockage en RAM . Évalué à 4.
Je… Je…
Vous avez raison. Mea maxima culpa !
# C'est bien mais...
Posté par JulienG . En réponse au journal Présentation de Serge : un outil de veille Libre. Évalué à 1.
Bonjour,
Initiative louable. Pour ma part, j'ai pris le contre-pied avec une logique de flux par poste/navigateur par le biais d’un module (dans les nouveautés : directement en WebExtension).
Quelques remarques sur les sources de SERGE :
les sources sont un peu en bazar (je suis mal placé pour en parler mais tant pis). Exemple : "databaseConnection" est dans "handshake" ? Pourquoi ? Ce ne serait pas plus simple d'avoir un module pour toute la gestion de BDD (par exemple insertSQL) ? Et que le module ne soit qu'une interface entre une BDD au choix et non MySQL ? Voir SQLAlchemy.
Le choix de SQL est judicieux pour un nombre "peu élevé" (à l'échelle d'une machine s'entend…) de données : pour des comptes utilisateurs, les flux RSS, etc. J'ai un doute par contre pour le choix du contenu des flux lui-même, qui n'a pas besoin des contraintes ACID : SQL est moins performant que noSQL. De plus SQL n'est pas scalable : une montée en charge impose de faire grossir un seul serveur, ce qui n'est plus dans la logique des orientations de SI. Notamment pour des professionnels.
Je n'ai rien vu d'handicapant pour le passage de Python2 à Python3, sinon que vous restez sur une logique synchro. Vu que vous allez bosser sur un même serveur, une logique asynchrone semble plus adapté pour le coeur pythonnique.
Pour le reste, le choix d'un IU par PHP est justifié mais il reste des choses assez étonnantes :
-- des fichiers erreurs individuellement codés à la main ??!! -> gestion par le HTaccess et redirection vers une page générique qui prend en charge l'erreur qui, par ailleurs, ne semble pas remonter au niveau admin -> pas de suivi des défauts ??!!
-- aucune utilisation rationnelle des templates : plein de pages PHP pas utiles.
-- pas de possibilité d'utiliser PHP pour contrôler les scripts Python ?! C'est mal -> à modifier d'urgence !
Sur le choix du Wiki : j'aime bien Dokuwiki dont la base est "flat". Rejoint ma remarque sur SQL/noSQL.
… Ainsi il me semble modestement :
la logique d'ensemble est mal foutue : il faut un outil scallable, qui est en Python et reçoit des commandes de partout, y compris de pair (de serveurs comme lui). Les commandes validées (question de sécurité) en local et générée par PHP à la demande de l'utilisateur, par le biais du serveur Web (ou alors en interne de Python avec CGI), pour gérer l'ensemble des flux sans passer par la BDD, ce qui soulage le moteur de BDD et le renvoi à sa condition de gérer des données par de la configuration.
A défaut de passer en asynchrone pour Python, des tâches CRON sont peut-être plus adaptée pour des flux RSS avec un verrou pour éviter la double lecture simultanée,
rationnaliser les fichiers de configuration : le changement de mots de passe de BDD dans votre situation est par exemple, problématique…
question des sauvegardes, des insertions d'anciennes sauvegardes : pas gérées ?! Quid des défauts et des relances de tâches (cf daemonisation).
Enfin si vraiment vous voulez du simple : serveur en Python avec des API (bien documentée et bien pensée) en REST pour donner des ordres. CURL ou WGET pour les appels, par le biais de CRON, sur le système hôte. PHP pourra ainsi dialoguer avec le coeur de Serge avec un simple "include". Vous diviserez par deux vos problèmes et la taille du code !
Et si vraiment l'interprocessus devient impératif face à la montée en charge, toujours dans la logique d'API : XML-RPC + un verrou entre deux serveurs.
Pour les autorisations: les JSON Web Tokens sont vos amis pour la vie.
Bonne journée,
Julien.