Je voulais donner mon avis, et ça tombe bien, ta réponse me permet non pas de te contredire ou d'appuyer le travail de steckdenis, mais de recadrer le débat :
De quoi parle-t-on ?
On parle :
- D'un logiciel dont le rôle est de lire et transmettre des données de type chaîne de caractère
- D'établir des liens entre ces données ( algo de résolutions des dépendances )
-Et à partir de là, d'établir une chaîne de logiciels à installer, désinstaller, mettre à jour. ( algo d'installation et désinstallation )
Pour ta remarque sur l'absence de Framework de création de paquet, je pense que n'importe quel RAD dispose de quoi fabriquer un bouton " creer paquet SETUP " permettant de remplir des champs composés de contenus de noeuds XML. Donc, ça, ça devrait être 8 heures de boulot sans aucun problème, sur la base du contenu du fichier XML présenté.
Donc pour ce plugin de création de paquets SETUP, personnellement je considère que l'affaire est déjà réglée. ( faut pas sous estimer le temps pour le réaliser et le tester, bien sûr , mais c'est loin d'être rédhibitoire .
Pour la " productivité ", j'ai l'impression que personne n'a compris le fonctionnement :
Alors qu'un logiciel de gestion des logiciels traditionnel fonctionne la plupart du temps en relation avec une BDD, que presque tout se passe dans les requêtes SQL et dans les jointures des tables ( j'exagère, je n'ai aucune idée de la façon dont fonctionne RPMDrake ) , ici, SteckDenis nous propose une vision fondamentalement beaucoup plus réfléchie.
En constatant _ et c'est une réalité _ la lourdeur de réaction du fonctionnement direct au dessus d'un SQLite ou autre, il nous propose de ( je traduis pour ceux qui n'auraient pas pigé ) _ Charger en mémoire vive ( RAM ) beaucoup plus rapide pour la manipulation de grandes quantités de données , toutes les info permettant de :
- connaitre le nom et la version du logiciel
- connaitre les bibliothèques ( libraries ) qui en dépendent.
- pointer vers les adresses des paquets dans la base de donnée.
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
C'est quelques centièmes à quelques dixièmes de secondes en C pour lire un fichier d'1 Mo par exemple . Je suppose qu'en C++, ça va être un peu plus lent, mais c'est rien comparé à la lecture de la même quantité de données dans une table SQL !
A la suite de ce chargement, le logiciel ( SETUP ) va pouvoir réaliser tous les traitements algorithmiques que vous voulez.
Une fois décidé quels logiciels doivent être installés/désinstallés/mis à jour, le logiciel peut alors réaliser un _post_traitement _ très rapidement :
La vérification de la non imbrication d'un certain nombre de logiciels permettant de réaliser une installation parrallélisée. ( un peu grillé par FreeBSD-8.0 sur ce coup-là :) ).
Il est évident que ce genre de travail aura des répercussions sur tous les gestionnaires de paquets du monde . Et ça, c'est bien. ( surtout si c'est libre ).
Steckdenis, franchement, continue, ça fait plaisir de voir des gens qui se défoncent , surtout ici .
[^] # Re: pas d'accord
Posté par houra . En réponse au journal Sortie de Setup 0.1-alpha0. Évalué à 2.
De quoi parle-t-on ?
On parle :
- D'un logiciel dont le rôle est de lire et transmettre des données de type chaîne de caractère
- D'établir des liens entre ces données ( algo de résolutions des dépendances )
-Et à partir de là, d'établir une chaîne de logiciels à installer, désinstaller, mettre à jour. ( algo d'installation et désinstallation )
Pour ta remarque sur l'absence de Framework de création de paquet, je pense que n'importe quel RAD dispose de quoi fabriquer un bouton " creer paquet SETUP " permettant de remplir des champs composés de contenus de noeuds XML. Donc, ça, ça devrait être 8 heures de boulot sans aucun problème, sur la base du contenu du fichier XML présenté.
Donc pour ce plugin de création de paquets SETUP, personnellement je considère que l'affaire est déjà réglée. ( faut pas sous estimer le temps pour le réaliser et le tester, bien sûr , mais c'est loin d'être rédhibitoire .
Pour la " productivité ", j'ai l'impression que personne n'a compris le fonctionnement :
Alors qu'un logiciel de gestion des logiciels traditionnel fonctionne la plupart du temps en relation avec une BDD, que presque tout se passe dans les requêtes SQL et dans les jointures des tables ( j'exagère, je n'ai aucune idée de la façon dont fonctionne RPMDrake ) , ici, SteckDenis nous propose une vision fondamentalement beaucoup plus réfléchie.
En constatant _ et c'est une réalité _ la lourdeur de réaction du fonctionnement direct au dessus d'un SQLite ou autre, il nous propose de ( je traduis pour ceux qui n'auraient pas pigé ) _ Charger en mémoire vive ( RAM ) beaucoup plus rapide pour la manipulation de grandes quantités de données , toutes les info permettant de :
- connaitre le nom et la version du logiciel
- connaitre les bibliothèques ( libraries ) qui en dépendent.
- pointer vers les adresses des paquets dans la base de donnée.
L'utilisation de la RAM, c'est beaucoup, beaucoup plus rapide que les utilisations par table SQL et fichiers XML.
C'est quelques centièmes à quelques dixièmes de secondes en C pour lire un fichier d'1 Mo par exemple . Je suppose qu'en C++, ça va être un peu plus lent, mais c'est rien comparé à la lecture de la même quantité de données dans une table SQL !
A la suite de ce chargement, le logiciel ( SETUP ) va pouvoir réaliser tous les traitements algorithmiques que vous voulez.
Une fois décidé quels logiciels doivent être installés/désinstallés/mis à jour, le logiciel peut alors réaliser un _post_traitement _ très rapidement :
La vérification de la non imbrication d'un certain nombre de logiciels permettant de réaliser une installation parrallélisée. ( un peu grillé par FreeBSD-8.0 sur ce coup-là :) ).
Il est évident que ce genre de travail aura des répercussions sur tous les gestionnaires de paquets du monde . Et ça, c'est bien. ( surtout si c'est libre ).
Steckdenis, franchement, continue, ça fait plaisir de voir des gens qui se défoncent , surtout ici .
Sedullus dux et princeps Lemovicum occiditur