Effectivement, ta pensée était éloignée de ce que j'avais compris. Cependant si tu as une configuration X, un fichier d'entrée Y et que tu t'attends que ça fonctionne - pour Robert ou un autre -, c'est illusoire.
Soit tu ne changes pas la configuration, soit tu la changes et tu adaptes ton entrée à ton changement.
N'est-ce pas comme ça pour tous les logiciels qui existent ?
Exemple : il attend du TOML, tu lui fournis un JSON, ça coince. L'exemple est caricatural mais la logique suivie est la même. Ton programme a son environnement et ses possibilités. Si tu en sors, tu sors du fonctionnement normal et attendu.
D'autant que tu ne compiles pas non plus ton logiciel tous les 4 matins. Tu peux même automatiser ta compilation pour les nouvelles versions, afin de modifier la valeur configurée pour l'adapter à ce qui existe déjà et que ta version soit adaptée à ton usage.
Je suis d'accord. C'est un nouveau projet : l'UTF-8 est LE standard, il convient de l'utiliser le plus possible (tout le temps).
Qu'un programme nécessite des impératifs particuliers dans un environnement complexe (embarqué, industriel, etc.) ou alors pour des questions de compatibilité avec des versions antérieures, ça s'entend.
Je ne suis pas sûr que ça soit pertinent de faire cette comparaison (enfin si, j'en suis sûr mais je suis trop poli pour le dire).
Je parle d'une modification avant compilation, avec d'autres critères à prendre en compte pour que le programme (celui-ci ou un autre) fasse ce que l'on souhaite.
De plus, c'est la modification d'un type char : quelque soit sa valeur, il est toujours de type char… ça ne modifie en RIEN le fonctionnement logique ou interne.
Certes c'est problématique dans ce cas-là. J'en suis conscient. Cependant il y a beaucoup de cas où le support de l'UTF-8 n'est pas un problème.
Par ailleurs, compte tenu de l'organisation du projet, il est très facile de modifier les caractères séparateurs. Peut-être faut-il cependant que j'améliore encore ce point, en passant les caractères séparateurs directement en variable globale dans le fichier de configuration. Ainsi la modification serait unique avant la compilation, et obtenu un programme qui répond à un usage plus limité.
Seulement si vous êtes gentil avec lui et ses frères. Le petit Robert est plus casanier, toujours plongé dans un grand nombre de pages… ;)
Plus sérieusement : oui, avec des modifications, car aujourd'hui l'outil de diffusion des messages porte sur les messages des clients entre eux.
La souscription devrait être modifiée comme suit :
- soit message entre clients ;
- soit le suivi des valeurs (modifiées / ajoutées / supprimées) - ce qui permettrait de créer une instance maîtresse et des instances enfantes.
Pour "clusterister" un gros volume de données entre plusieurs instances, tout dépend du projet et de la formalisation derrière. Je n'ai pas vraiment de réponse. En soi ça me semble tout à fait possible, mais je n'ai pas réfléchi à une mise à mettre en œuvre.
Oui il sera lu, par moi-même et j'espère beaucoup d'autres !, dans le futur. En français, comme des centaines de millions de personnes dans le monde : https://fr.wikipedia.org/wiki/Francophonie
Quelqu'un qui ne parle pas le français fera comme moi quand je lis le commentaire du code source (en mandarin) de ma box 4G chez Bouygues : il utilisera un outil de traduction.
Si l'on tient à rester sur le cadre purement logique, les noms de variables apportent un sens et facilite la compréhension, mais on peut aussi retrouver le fonctionnement avec la grammaire d'un langage.
Je vois que cette question irrite beaucoup dans les commentaires. Je suis (réellement) surpris.
J'attire votre attention que la transposition professionnelle de la thèse n'est pas publique et n'est donc pas présent dans le document (seulement la partie sur le modèle RDF appliquée aux entreprises et l'intérêt du fonctionnel dans le développement moderne).
Sur les structures, il y en a pas mal : les canaux en sont, les clients (stream TCP avec d'autres paramètres), le contexte d'utilisation (qui regroupe l'état du service, du client, les accès mutex, etc.), ainsi que les valeurs.
Chacun a son implémentation propre, avec des traits pour la généricité, notamment pour l'écriture sur le socket du client.
L'ensemble est dans un canevas d'exécution (une fonction, retrouvée lors du traitement d'une commande) qui doit répondre à un type particulier, indépassable.
(Pour le point sur le français, j'ai publié un commentaire précédent sur le sujet)
J'espère ne pas dire de bêtise, mais Memcached ne gère pas des objets complexes, permettant la récursivité. Il gère des données binaires et des flags (il """ne comprend pas""" ce qu'il stocke).
Robert peut être considéré comme un gestionnaire de canaux où chacun gère un arbre, doté d'une profondeur qui peut évoluer sans grande limite, sur des types fixés à l'avance.
J'ai essayé de créer un environnement très favorable à l'ajout de nouvelles commandes (on ajoute une fonction avec deux arguments - permettant d'obtenir le contexte d'exécution et les arguments fournis - avec un retour à destination du client, on compile, c'est prêt).
En dehors de projets éducatifs je ne comprends pas l’intérêt étant donné la masse de documentations et projets existants en anglais.
En rapport avec le choix de la langue, pour moi c’est un frein à l’adoption : on privilégie sa localité au détriment des autres. Ça me rappelle tous ces projets en Chinois dont on ne peut pratiquement rien faire car il n’existe aucune documentation en anglais.
Ça donne aussi un mélange très étrange entre anglais et français, vu que le langage et la lib standard sont en anglais. Ça fait encore plus de gymnastique pour passer de l’un à l’autre.
De plus, au niveau du code, ça n’a amha que peu d’importance : les utilisateurs utilisent un binaire, pas du code source.
Certes. L'anglais est une convention. Une convention est par nature, une convention : ce qui est convenu dans un groupe donné. Aucune langue n'est éternelle, sans évolution. Je ne crois pas que l'anglais le soit pour l'informatique car, comme tu le soulignes, l'indien ou le chinois ont un poil plus d'utilisateurs (surtout réunis) dans les informaticiens que ceux du bloc classique occidental dans un proche avenir (si ce n'est pas déjà le cas).
Le débat sur ce point, fait de ma position une position ultra-minoritaire j'en suis conscient. Mais je crois qu'il faut des projets qui ne soit pas nécessairement en anglais "parce que c'est comme ça". Pour moi, fondamentalement, c'est un rapport d'abord à la communauté que l'on créée, où l'on est, où l'on agit.
Pour la lib standard, justement. Combien - je m'inclue dedans - ont passé parfois des heures à comprendre tel ou tel point, en anglais ? Si la réponse est "Google Translate" alors soit, c'est "Google Translate" - mais ce qui est valable anglais -> français est donc valable français -> anglais.
Pour l'utilisateur lambda, la doc et le code en français peut avoir un sens car le français ne se limite pas à la France et est une communauté parmi les plus nombreuses au monde.
Par contre on est d'accord : en soi du code en français, on s'en fiche, d'autant que ce qui compte c'est que la machine comprenne les instructions…
Pour ce qui est de la traduction des « crate » Rust, je ne pense pas que cela rende les choses plus claires :)
Non, et Rust est limité en pouvoir descriptif dans ses concepts. Juste le terme "module" reprend parfois des choses différentes, entre une "caisse", un fichier du projet..
Selon les objectifs, tout refaire sois-même peut-être autant sinon plus de code à maintenir, sans parler des problèmes de sécurité/performance résolus par d’autres projets.
Choisir consciencieusement ses dépendances est à mon avis plus intéressant. Tu prends l’exemple de Regex, je pensais aussi à ce genre de chose, mais pas que. Il existe des bibliothèques permettant d’atteindre des performances bien meilleures que les dictionnaires (hashmap/hashset) de la lib standard par exemple.
Tu as tout à faire raison, c'est un risque. Mais comme c'est sous-entendu, le risque était soit de faire un rassemblement de projets extérieurs avec des dépendances qui, sérieusement, ne seraient relues (et potentiellement seraient abandonnées), soit le refaire et avoir un projet homogène dans sa maturation. J'ai fait le choix de l’homogénéité.
Sur Hashmap, j'ai pris le choix d'aller vers la simplicité conceptuelle : une paire clé/valeur pour chaque entrée, qui sont rassemblées ensemble. Hashset aurait impliqué de faire un travail supplémentaire, car le hash est sur l'objet stocké et non sur la clé. Hashmap a une gestion des clés par hash.
En terme de code (j’ai largement survolé, de très très haut), je vois que tu te sers de HashMap provenant de la lib standard. Les performances de ce type sont vraiment mauvaises : les implémentations de Python et Go font largement mieux par exemple. S’il y a une volonté d’être performant, il faut absolument s’orienter vers d’autres implémentations en attendant.
De fait si l'on prend toutes les attendus du projet (intégrité de l'outil ; support natif ; performance ; simplicité conceptuelle et de maintenance), je trouve que c'est un choix raisonnable.
J'entends parfaitement ce que c'est pas le choix le plus performant (encore que), mais c'est un choix qui ne prend pas que la performance.
Pour la comparaison avec Python, compte tenu que Rust est compilé avec des performances très proches du C, j'ai un doute que l'implémentation soit moins bonne. Pour Go, je sais pas trop.
Tu me mets le doute, je vais regarder et tester ça.
Si je comprends bien c’est à la fois un "pub/sub" et une "base" comme on pourrait en avoir dans redis ?
Oui je crois.
Quel est l’intérêt par rapport à une modélisation "à plat" clef-valeur toute simple ?
En terme de performance, cela veut dire qu’à chaque fois que l’on veut traverser des objets, il faut charger en cascade des espaces mémoire aléatoirement dans la RAM.
En terme d’usage, je ne vois pas d’avantage à simplement avoir une clef correspondant au chemin complet, et une valeur au bout. Sauf peut-être pour l’expiration d’un groupe de valeurs, éventuellement.
Peux-tu m’éclairer à ce sujet ?
Bien sûr. L'actualité n'est sûrement pas clair. Le canal dispose d'une hashmap qui est une valeur comme une autre, de type "objet" (qui contient donc d'autres valeurs). Le chemin correspond à tous les objets à traverser pour atteindre la valeur finale (qui est un des 5 types).
Ce n'est donc pas du tout une base "à plat" mais un arbre de hashmap, dont l'origine est le canal lui-même (j'espère que c'est plus clair ?).
Sur la partie scripting, j’ai pas compris le choix d’un caractère "difficile" à taper, limitant encore plus l’accessibilité : ø. Si c’était pour désambiguïser l’usage du "o" et du "0", ok, mais alors choisir un caractère facilement accessible me semble judicieux.
Ce n'est pas pour l’ambiguïté, mais au contraire pour être sûr que le scripteur veux bien l'inconditionnalité (c'est-à-dire que la commande sera toujours exécutée).
Voilà mon petit retour :) Personnellement je ne vois pas d’intérêt de ce projet par rapport à Redis, ou même memcached si ce n’est l’utilisation d’un langage théoriquement exempt de problèmes de pointeurs null et autres overflows.
Ce qui est déjà pas mal tu ne crois pas ? Beaucoup de choses dans la surface d'attaque ou de problématiques portent sur la question des pointeurs et des débordements.
Après peu importe, c’est toujours une bonne expérience de faire quelque chose de concret, et j’espère que mon commentaire pourra t’apporter quelque chose.
Je te remercie de ton commentaire, qui me permet d'être, j'espère, plus clair et précis, comme d'argumenter sur le projet.
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é à -2. Dernière modification le 21 avril 2020 à 16:34.
Effectivement, ta pensée était éloignée de ce que j'avais compris. Cependant si tu as une configuration X, un fichier d'entrée Y et que tu t'attends que ça fonctionne - pour Robert ou un autre -, c'est illusoire.
Soit tu ne changes pas la configuration, soit tu la changes et tu adaptes ton entrée à ton changement.
N'est-ce pas comme ça pour tous les logiciels qui existent ?
Exemple : il attend du TOML, tu lui fournis un JSON, ça coince. L'exemple est caricatural mais la logique suivie est la même. Ton programme a son environnement et ses possibilités. Si tu en sors, tu sors du fonctionnement normal et attendu.
D'autant que tu ne compiles pas non plus ton logiciel tous les 4 matins. Tu peux même automatiser ta compilation pour les nouvelles versions, afin de modifier la valeur configurée pour l'adapter à ce qui existe déjà et que ta version soit adaptée à ton usage.
Bref à mon sens, ça reste hors de propos.
[^] # 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.
Je suis d'accord. C'est un nouveau projet : l'UTF-8 est LE standard, il convient de l'utiliser le plus possible (tout le temps).
Qu'un programme nécessite des impératifs particuliers dans un environnement complexe (embarqué, industriel, etc.) ou alors pour des questions de compatibilité avec des versions antérieures, ça s'entend.
Mais là… ? Je suis perplexe.
[^] # 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é à 1.
Je ne suis pas sûr que ça soit pertinent de faire cette comparaison (enfin si, j'en suis sûr mais je suis trop poli pour le dire).
Je parle d'une modification avant compilation, avec d'autres critères à prendre en compte pour que le programme (celui-ci ou un autre) fasse ce que l'on souhaite.
De plus, c'est la modification d'un type
char: quelque soit sa valeur, il est toujours de typechar… ça ne modifie en RIEN le fonctionnement logique ou interne.[^] # 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é à 1.
Certes c'est problématique dans ce cas-là. J'en suis conscient. Cependant il y a beaucoup de cas où le support de l'UTF-8 n'est pas un problème.
Par ailleurs, compte tenu de l'organisation du projet, il est très facile de modifier les caractères séparateurs. Peut-être faut-il cependant que j'améliore encore ce point, en passant les caractères séparateurs directement en variable globale dans le fichier de configuration. Ainsi la modification serait unique avant la compilation, et obtenu un programme qui répond à un usage plus limité.
Merci de votre retour.
[^] # Re: Hautement escaladable?
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Seulement si vous êtes gentil avec lui et ses frères. Le petit Robert est plus casanier, toujours plongé dans un grand nombre de pages… ;)
Plus sérieusement : oui, avec des modifications, car aujourd'hui l'outil de diffusion des messages porte sur les messages des clients entre eux.
La souscription devrait être modifiée comme suit :
- soit message entre clients ;
- soit le suivi des valeurs (modifiées / ajoutées / supprimées) - ce qui permettrait de créer une instance maîtresse et des instances enfantes.
Pour "clusterister" un gros volume de données entre plusieurs instances, tout dépend du projet et de la formalisation derrière. Je n'ai pas vraiment de réponse. En soi ça me semble tout à fait possible, mais je n'ai pas réfléchi à une mise à mettre en œuvre.
[^] # Re: Conflit sur le nom «Robert»
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 1.
Heureusement nous ne sommes pas au même niveau de visibilité (loin, très très loin), aussi je doute leur faire de l'ombre :)
Il y a une indication en début d'article sur ce sujet.
[^] # 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é à 4.
Oui il sera lu, par moi-même et j'espère beaucoup d'autres !, dans le futur. En français, comme des centaines de millions de personnes dans le monde :
https://fr.wikipedia.org/wiki/Francophonie
Quelqu'un qui ne parle pas le français fera comme moi quand je lis le commentaire du code source (en mandarin) de ma box 4G chez Bouygues : il utilisera un outil de traduction.
Si l'on tient à rester sur le cadre purement logique, les noms de variables apportent un sens et facilite la compréhension, mais on peut aussi retrouver le fonctionnement avec la grammaire d'un langage.
Je vois que cette question irrite beaucoup dans les commentaires. Je suis (réellement) surpris.
[^] # Re: Supports téléchargeables ?
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 4.
Voici un lien pour télécharger directement le PDF :
https://drive.google.com/file/d/1_YyU2jGJn4-4Iu8c25n1VeSU0jRcwgYx/view?usp=sharing
J'attire votre attention que la transposition professionnelle de la thèse n'est pas publique et n'est donc pas présent dans le document (seulement la partie sur le modèle RDF appliquée aux entreprises et l'intérêt du fonctionnel dans le développement moderne).
[^] # Re: Comparaison ?
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Je regarde pour faire un exemple d'usage.
[^] # 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.
Sur les structures, il y en a pas mal : les canaux en sont, les clients (stream TCP avec d'autres paramètres), le contexte d'utilisation (qui regroupe l'état du service, du client, les accès mutex, etc.), ainsi que les valeurs.
Chacun a son implémentation propre, avec des traits pour la généricité, notamment pour l'écriture sur le socket du client.
L'ensemble est dans un canevas d'exécution (une fonction, retrouvée lors du traitement d'une commande) qui doit répondre à un type particulier, indépassable.
[^] # Re: lapin compris
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
Non malheureusement, je n'ai aucun comparatif à te fournir. J'espère pouvoir le faire très bientôt.
[^] # Re: Comparaison ?
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
(Pour le point sur le français, j'ai publié un commentaire précédent sur le sujet)
J'espère ne pas dire de bêtise, mais Memcached ne gère pas des objets complexes, permettant la récursivité. Il gère des données binaires et des flags (il """ne comprend pas""" ce qu'il stocke).
Robert peut être considéré comme un gestionnaire de canaux où chacun gère un arbre, doté d'une profondeur qui peut évoluer sans grande limite, sur des types fixés à l'avance.
J'ai essayé de créer un environnement très favorable à l'ajout de nouvelles commandes (on ajoute une fonction avec deux arguments - permettant d'obtenir le contexte d'exécution et les arguments fournis - avec un retour à destination du client, on compile, c'est prêt).
[^] # 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é à 10.
Merci !
Certes. L'anglais est une convention. Une convention est par nature, une convention : ce qui est convenu dans un groupe donné. Aucune langue n'est éternelle, sans évolution. Je ne crois pas que l'anglais le soit pour l'informatique car, comme tu le soulignes, l'indien ou le chinois ont un poil plus d'utilisateurs (surtout réunis) dans les informaticiens que ceux du bloc classique occidental dans un proche avenir (si ce n'est pas déjà le cas).
Le débat sur ce point, fait de ma position une position ultra-minoritaire j'en suis conscient. Mais je crois qu'il faut des projets qui ne soit pas nécessairement en anglais "parce que c'est comme ça". Pour moi, fondamentalement, c'est un rapport d'abord à la communauté que l'on créée, où l'on est, où l'on agit.
Pour la lib standard, justement. Combien - je m'inclue dedans - ont passé parfois des heures à comprendre tel ou tel point, en anglais ? Si la réponse est "Google Translate" alors soit, c'est "Google Translate" - mais ce qui est valable anglais -> français est donc valable français -> anglais.
Pour l'utilisateur lambda, la doc et le code en français peut avoir un sens car le français ne se limite pas à la France et est une communauté parmi les plus nombreuses au monde.
Par contre on est d'accord : en soi du code en français, on s'en fiche, d'autant que ce qui compte c'est que la machine comprenne les instructions…
Non, et Rust est limité en pouvoir descriptif dans ses concepts. Juste le terme "module" reprend parfois des choses différentes, entre une "caisse", un fichier du projet..
Tu as tout à faire raison, c'est un risque. Mais comme c'est sous-entendu, le risque était soit de faire un rassemblement de projets extérieurs avec des dépendances qui, sérieusement, ne seraient relues (et potentiellement seraient abandonnées), soit le refaire et avoir un projet homogène dans sa maturation. J'ai fait le choix de l’homogénéité.
Sur Hashmap, j'ai pris le choix d'aller vers la simplicité conceptuelle : une paire clé/valeur pour chaque entrée, qui sont rassemblées ensemble. Hashset aurait impliqué de faire un travail supplémentaire, car le hash est sur l'objet stocké et non sur la clé. Hashmap a une gestion des clés par hash.
De fait si l'on prend toutes les attendus du projet (intégrité de l'outil ; support natif ; performance ; simplicité conceptuelle et de maintenance), je trouve que c'est un choix raisonnable.
J'entends parfaitement ce que c'est pas le choix le plus performant (encore que), mais c'est un choix qui ne prend pas que la performance.
Pour la comparaison avec Python, compte tenu que Rust est compilé avec des performances très proches du C, j'ai un doute que l'implémentation soit moins bonne. Pour Go, je sais pas trop.
Tu me mets le doute, je vais regarder et tester ça.
Oui je crois.
Bien sûr. L'actualité n'est sûrement pas clair. Le canal dispose d'une hashmap qui est une valeur comme une autre, de type "objet" (qui contient donc d'autres valeurs). Le chemin correspond à tous les objets à traverser pour atteindre la valeur finale (qui est un des 5 types).
Ce n'est donc pas du tout une base "à plat" mais un arbre de hashmap, dont l'origine est le canal lui-même (j'espère que c'est plus clair ?).
Ce n'est pas pour l’ambiguïté, mais au contraire pour être sûr que le scripteur veux bien l'inconditionnalité (c'est-à-dire que la commande sera toujours exécutée).
Ce qui est déjà pas mal tu ne crois pas ? Beaucoup de choses dans la surface d'attaque ou de problématiques portent sur la question des pointeurs et des débordements.
Je te remercie de ton commentaire, qui me permet d'être, j'espère, plus clair et précis, comme d'argumenter sur le projet.
[^] # 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.