Journal Requête aux devs de logiciels libres

Posté par .
Tags : aucun
31
4
jan.
2010
Je trouve que la direction prise par Linux et les logiciels libres en général s'éloigne de plus en plus du concept KISS ....

De plus en plus de logiciels génèrent des fichiers de conf XML. Personnellement j'aimerais qu'on m'explique l'intéret. En effet, un fichier XML a de l'intéret dans un contexte ou une appli doit pouvoir communiquer avec d'autres applis, ou si un document doit pouvoir être lu par une autre application. Mais qu'en est-il d'un fichier de conf ? Il ne concerne que l'appli pour laquelle le fichier de conf est généré, donc pas d'interopérabilité nécessaire. On perd donc en lisibilité et en simplicité pour se coltiner un format trop verbeux. Le seul intéret que je vois (et de loin), c'est de pouvoir traduire un fichier de conf pour la version N d'un logiciel vers un fichier de conf pour une version N+1 du même soft. Mais la je trouve quand même que c'est sortir l'artillerie lourde pour pas grand chose .....

Autre point (qui à mon avis découle du précédent) : des utilitaires censés être configurés en environnement serveur (sur lesquels il est très rare de trouver un serveur X), en viennent à ne proposer que des utilitaires de configuration graphique. Je pense en particulier à Redhat Cluster Suite qui fait fort dans son genre. Je le trouvais bien jusqu'à ce que je constate que le fichier de conf est en XML (beurk mais si ce n'était que ça ...), et qu'il est impossible de le configurer via ligne de commande. C'est complêtement pourri ce truc : je dois le faire sur un environnement pour lequel le débit réseau n'est pas très important, et le nombre de ports ouverts depuis l'extérieur est limité. Si seulement je pouvais ajouter mes services via une commande bien sentie, je m'en contenterais ais là c'est même pas possible.

Tout ça pour vouis demander Mr les développeurs, de ne pas céder à la mode stupide des fichiers de conf en XML, et de ne pas ouvblier également que le GUI n'est pas la panacée pour des softs cen sés se trouver en salles serveur, sans serveur X accessible facilement. Si vous voulez mettre des GUI, pourquoi pas, mais surtout n'oubliez pas que vos softs peuvent être utilisés sur des serveurs n'ayant même pas de carte graphique.
  • # Vous devez entrer un sujet et un commentaire

    Posté par (page perso) . Évalué à 10.

    Le probleme c'est que parser un fichier de conf c'est super penible si tu dois tout construire à partir de fgetc() et feof()..

    Et comme les parseurs XML sont assez courants, ben c'est plutot logique de ne pas se casser la tete à reecrire un parseur. Et pourtant dieu sait que je hais le XML et sa bloatitude.
    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par . Évalué à 10.

      Oui mais pour qui est écrit le soft ? Pour l'utilisateur ou pour le développeur. L'argument que tu avences ne me parait pas un argument valable : depuis le temps qu'on fait des softs avec des fichiers de conf texte, ça a déjà été fait, le code libre existe.
      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par . Évalué à 3.

        Souvent, l'utilisateur est un développeur. Ou même le logiciel est pensé pour être intégré dans un "workflow" (pas de traduction qui me vient direct à l'esprit) plus grand que tu ne peux le voir et donc le fichier de conf n'est qu'un "détail" qui peut être généré à l'autre bout du workflow.
      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par . Évalué à 4.

        Oui mais pour qui est écrit le soft ? Pour l'utilisateur ou pour le développeur.

        Pour ce qui est des logiciels libre, l'utilisateur est bien gentil mais à moins qu'il donne un peu de son temps ou de son argent, il n'a pas vraiment à poser ses exigences concernant ce qui lui est gracieusement offert.

        Un développeur qui travaille bénévolement sur un projet fait ce qui est le plus simple pour lui. C'est un peu comme à chaque fois que quelqu'un développe un petit soft en Java ou autre et que des tas de râleurs viennent l'engueuler et dire qu'il aurait du le coder C/Python/Lua/assembleur/... Le gars fait ce qu'il veut. Il n'oblige personne à utiliser son soft et les contributions sont les bienvenues sauf que bizarrement, on n'en voit pas beaucoup venir du côté des râleurs.
    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par (page perso) . Évalué à 6.

      La GLib gère les fichiers « key-value », c'est simple à utiliser tant pour le programmeur que pour l'utilisateur qui veut modifier le fichier de conf.

      Je pense que dans la plupart des cas c'est amplement suffisant, et donc pas besoin de réécrire un parseur.

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par . Évalué à 6.

        Dans l'exemple cité (le cluster tool), arrêtez moi si je me trompe mais la structure doit être suffisamment compliquée pour qu'un simple fichier key-value soit un poil insuffisant.
        • [^] # Re: Vous devez entrer un sujet et un commentaire

          Posté par . Évalué à 2.

          Pas si complexe que ça. En tout cas ça n'atteint pas la complexité d'un document OpenOffice. .... A la limite a défaut de pouvoir touiller le fichier de conf à la main, il aurait été sympa d'avoir un outil en ligne de commande permettant de manipuler le fichier. Aparamment ça a existé sur les anciennes versions de RedHat Cluster Suite mais pas sur les versions récentes.
      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par . Évalué à 4.

        Oue, m'enfin la le monsieur il se plaint des fichiers de conf XML qu'il ne trouve pas "beaux" et trop complexes, alors linker avec la glib juste pour lire un fichier de conf a plat, il va nous faire une attaque.

        Le bloat du parseur et des fichiers XML, a cote d'une dependance sur la glib, ca fait petit joueur.

        En plus dans le cas des applis qui utilisent du XML, on peut se dire que generalement c'est qu'elles ont besoin de stocker des donnees de facon hierarchique. Et la tes fichiers key-value, ca marche plus trop bien de facon portable.
        • [^] # Re: Vous devez entrer un sujet et un commentaire

          Posté par (page perso) . Évalué à 4.

          Ils pourraient utiliser du yaml, qui est somme toute bien plus lisible que du xml.

          http://en.wikipedia.org/wiki/Yaml
          • [^] # Re: Vous devez entrer un sujet et un commentaire

            Posté par (page perso) . Évalué à 2.

            Exactement ! Le XML ne devrait jamais être modifié par un utilisateur. C'est tout simplement trop chiant.

            DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Re: Vous devez entrer un sujet et un commentaire

            Posté par (page perso) . Évalué à 9.

            personnellement, je ne trouve pas yaml plus lisible, tout simplement parce que la syntaxe est finalement super compliquée, avec plein de signes différents, et des règles plutôt compliquées. (genre --- | vs --- > : désolé, mais à lire ça comme ça, je ne comprendre pas ce que ça veut dire, sans aller lire la spec)

            Alors que XML, ok, c'est plus verbeux, mais c'est bien plus simple à écrire.


            Franchement, YAML, ça ne vaut vraiment pas la pire des syntaxes wiki. C'est du grand bricolage et c'est tout sauf simple.

            Quitte à utiliser un format de fichier de conf structuré sans passer par XML, autant prendre JSON. Il n'y a pas 50 signes cabalistiques à apprendre, même pour pondre des données complexes.
          • [^] # Re: Vous devez entrer un sujet et un commentaire

            Posté par . Évalué à 4.

            Mon dieu quelle horreur. XML a le tord d'être verbeux et de nécessiter de taper beaucoup de caractères de formatage/ponctuation mais au moins le principe est simple (balise ouvrante/balise fermante, attributs). Yaml est une monstruosité. Il y a tellement de règles, de syntaxes et constructions différentes qu'il est bien difficile de dire à première vue si un document est syntaxiquement correct ou pas. Et puis le code d'un parseur Yaml doit être au moins aussi volumineux et complexe que celui d'un parseur XML.
    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par . Évalué à 7.

      Pour parser des fichiers de confs, on utiliserait plutôt lex&yacc que le stdio de base. Un avantage (relativement faible quand même) d'XML serait qu'il n'y aurait pas à documenter le format de la conf concernant comment écrire les nombres, chaines de caractères ou commentaires. Par exemple, XML définit déjà qu'un commentaire s'écrit "<!-- -->".
    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par . Évalué à 2.

      Il y a quelques mois, j'avais la même réponse toute prête, parseur xml très répandu...

      Et puis j'ai découvert YAML (http://www.yaml.org/) un peu par hasard (oui je sais, je lag de plusieurs années). Depuis j'utilise ce format pour tous mes fichiers de conf et je me demande comment xml peut toujours être utilisé ?!
      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par . Évalué à 2.

        Comme pour Python, l'indentation est significative et ce genre de comportement ne met pas tout le monde d'accord.
        • [^] # Re: Vous devez entrer un sujet et un commentaire

          Posté par . Évalué à 1.

          Ca reste quand même plus lisible que du XML.
        • [^] # Re: Vous devez entrer un sujet et un commentaire

          Posté par . Évalué à 10.

          Je ne peux que te suivre. En effet les espaces significatifs dans le genre idée à la con c'est pas mal (copie coller un fichier de config en YAML sur linuxfr qui bouffe les espaces qu'on rigole coup).

          C'est pas beaucoup plus court ni plus lisible (cf. une veille discussion https://linuxfr.org//comments/1054702.html#1054702 ).

          Tu perds toute notion de schema et de documents valides. Du coup comment j'ai la complétion sur mes fichiers de config ou la documentation interactive directement dans mon éditeur ?

          Plus accessoire, tu dis adieu à tout les outils & toutes les transfos automatiques

          Non c'est sur ca n'a que des avantages pour gagner 100 caractères :-) Et pourtant je milite pour une utilisation raisonnée du XML...
        • [^] # Re: Vous devez entrer un sujet et un commentaire

          Posté par . Évalué à 6.

          En parlant de python et de fichiers de configuration, il y a un truc qui m'horripile concernant bon nombre de soft en python : Le fichier de configuration est souvent un fichier python. Le fichier de configuration n'est pas simplement lu, il est exécuté. Bonjour la sécurité.
          On peut insérer tout le code qu'on veut dans le fichier de config, ce code tournera comme le reste du programme sous l'identité de l'exécutant. En cas d'erreur de syntaxe dans le fichier de config, le programme plante (l'origine du problème n'est pas évidente), et en cas de modification mal intentionnée, ça peut tourner très mal. Un fichier de config doit être lu, jamais exécuté.
    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par . Évalué à 1.

      Il est aussi possible d'écrire la conf directement dans le langage du programme si celui-ci est interprété, ça permet souvent d'utiliser des constructions plus complexe (genre tableaux associatifs imbriqués), y'a pas besoin de bibliothèques supplémentaires et le coût est minimal pour le programmeur.
      Et même en C il serais pas forcément con d'écrire sa conf en lua, ça serais pas forcément plus lourd qu'un parseur XML tout en laissant plus de liberté à l'utilisateur.
      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par . Évalué à 6.

        Malheureusement, ça rend possible l'injection de saloperies dans l'application (puisque ta configuration devient carrément du code exécuté par l'application)
        • [^] # Re: Vous devez entrer un sujet et un commentaire

          Posté par . Évalué à 2.

          À part des cas vraiment particulier, genre binaire setuid ou Jean-Kevin qui copy/paste la conf qu'on lui a filé sur IRC, j'ai du mal à voir le problème :/
          C'est le même principe que tout les scripts type /etc/rc.conf sur un certain nombre d'Unix (genre Archlinux, pour rester dans le KISS).
      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par (page perso) . Évalué à 2.

        En C++, un parseur simple de couples clé=valeur ça prend quelques lignes:


        typedef map<string,string> ConfigMap;
        struct ConfigError
        {
        string message ;
        inline ConfigError(const string& msg)
        { message = msg ; } ;
        } ;
        class Config
        {
        private:
        ConfigMap m_pairs ;

        public:
        Config(const char* filepath) ;
        void get(const char* key, string& value, const char* defval=NULL) const ;
        } ;



        /*=============================================================================
        LECTURE DE CONFIGURATION
        =============================================================================*/
        Config::Config(const char* filepath)
        {
        string s ;
        ifstream configfile(filepath) ;
        while (configfile)
        {
        getline(configfile,s) ;
        if (not s.size() || s[0]=='#') continue ; // Ignore lignes vides et commentaires.
        int offset = s.find('=') ;
        string key(s.substr(0,offset)) ;
        string value(s.substr(offset+1,s.size())) ;
        m_pairs[key] = value ;
        }
        }
        void Config::get(const char* key, string& value, const char* defval) const
        {
        ConfigMap::const_iterator found = m_pairs.find(key) ;
        if (found == m_pairs.end()) // Retourne default.
        if (defval != NULL)
        value = defval ;
        else
        throw ConfigError((string("Unknown key: ")+key)) ;
        else
        value = (*found).second ;
        }

        Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

        • [^] # Re: Vous devez entrer un sujet et un commentaire

          Posté par (page perso) . Évalué à 5.

          Jusqu'au jour où tu te rends compte que tu dois gérer des valeurs longues et que les utilisateurs veulent les couper sur plusieurs lignes (donc gèrer les \ en fin de ligne), puis l'encodage des caractères spécieux, et puis les chaines entre "", puis les " a l'intérieur de ces chaines, puis les valeurs multiples, ignorer les espaces, sauf quand...

          Et finalement, tu passera ton temps a "améliorer" la syntaxe de ton fichier de conf, et a écrire du code avec des bugs.
          Au final, du xml, ça t'enlève pas mal de soucis déja connus et résolus depuis des lustres, avec comme seul coup un peu d'usure des touches < et >, un peu de ralage des utilisateurs, et éventuellement le besoin d'écrire et documenter une dtd/xsd

          Et en prime tu gagne le droit d'être la vedette lors des trolls a la machine à café...
      • [^] # Re: Vous devez entrer un sujet et un commentaire

        Posté par (page perso) . Évalué à 3.

        >Il est aussi possible d'écrire la conf directement dans le langage du programme

        et donc, impossible pour une application tierce (comme un clicodrome pour configurer ton truc, ou un outils tiers qui exploite les possibilités de ton appli) de lire ce fichier de conf, de le modifier ou autre...

        Personnellement, je trouve ça ballot.
    • [^] # Re: Vous devez entrer un sujet et un commentaire

      Posté par (page perso) . Évalué à 2.

      Il existe aussi des librairies de parsing bien développées.
      http://www.nongnu.org/confuse/

      Adhérer à l'April, ça vous tente ?

  • # XML et GUI ?

    Posté par . Évalué à 7.

    Le XML c'est pratique grâce à l'écosystème de librairie permettant de créer ou charger en mémoire des fichiers. De plus, dans un environnement "objet", c'est bien pratique pour "poser" les objets dans un fichier.
    D'autre format de fichier le font, mais XML le fait très bien, pour quasi tout les langage.

    Le rapport entre XML et GUI ?
    Il n'y en pas. :)

    Pourquoi les développeurs font des GUI ?
    Parce que ça permet de faire des choses basique sans avoir aucune compétence ou presque, et sans "perdre" de temps à faire un man appli. C'est bien ou pas ? Ce n'est pas à moi de le dire ! En tout cas, ce n'est pas mes interfaces graphiques qui t'embêterons, je n'en fait pas, ça me fait trop ch### :)
    • [^] # Re: XML et GUI ?

      Posté par . Évalué à 2.

      Le XML c'est pratique grâce à l'écosystème de librairie permettant de créer ou charger en mémoire des fichiers.
      C'est faisable sans XML : les tableaux associatifs sont intégrés dans la plupart des langages modernes, et cen'est pas dur d'écrire les libs en question (qui doivent exister depuis longtemps). Comment faisait-on avant XML ?

      La encore, c'est "pratique pour le développeur"


      Pourquoi les développeurs font des GUI ?
      Parce que ça permet de faire des choses basique sans avoir aucune compétence ou presque, et sans "perdre" de temps à faire un man appli.

      OK mais je perds du temps a me trouver une machine sur laquele je peux faire tourner un serveur X, installer un Linux dessus, instaler un VNC, faire un export du display et ensuite me battre avec les regles de filtrage pour accéder àmon VNC distant avec un débit minable, tout ca pour configurer un pauvre cluster. De plus ce n'est pas une interface graphique qui donne des compétences. Sinon il y a longtemps que voyages.sncf.com serait ergonomique rapide joli, tout ça ... vu le nombre d'outils graphiques permettant de faire de zolies pages web. Puis c'est sur qu'on ne perd pas de temps à faire un "man appli", on essaie des tas d'options, on clique sur l'aide en ligne et quand on se trompe le système envoie un message d'erreur stupide et imbitable car ça prend du temps de tester tous les cas possibles et imaginables, et on se retrouve a passer du temps à essayuer dans tous les sens l'option qui n'a pas marché. un man appli me donnera en général plus d'infos qu'un GUI.

      C'est bien ou pas ? Ce n'est pas à moi de le dire ! En tout cas, ce n'est pas mes interfaces graphiques qui t'embêterons, je n'en fait pas, ça me fait trop ch### :)

      Oh comme je te remercie. :). En tout cas dire que ce n 'est pas bien, oui je le dis. Rien que le fait qu'en environnement serveur, il est fort possible de ne pas disposer d'interface graphique devrait inciter les developpeurs à proposer une alternative. Sinon pourquoi ne pas installer un Windows ?
      • [^] # Re: XML et GUI ?

        Posté par . Évalué à 3.

        <code>C'est faisable sans XML : les tableaux associatifs sont intégrés dans la plupart des langages modernes, et cen'est pas dur d'écrire les libs en question (qui doivent exister depuis longtemps). Comment faisait-on avant XML ?</code>Mais que propose tu alors ?
        parce qu'entre


        <foret>
        <arbre type="sapin" />
        <arbre type="pommier">
        <fruit type="pomme" taille="4" />
        <fruit type="pomme" taille="2">
        <ver taille="3">
        </fruit>
        </arbre>
        <arbre type="sapin" />
        </foret>



        et




        foret {
        arbre {
        "type"=>"sapin"
        }
        arbre {
        "type"=>"pommier" ,
        fruit {
        "type"=>"pomme", "taille"=>"4"
        }
        fruit {
        "type"=>"pomme", "taille"=>"2",
        ver {
        "taille"=>"3"
        }
        }
        }
        arbre {
        "type"=>"sapin"
        }
        }

        Ba c'est pareil...!
        Il ne faut pas croire que c'est "pratique pour le développeur" alors il fait :

        Configuration.toXML().toString() ;

        C'est plus parce que l'équipe de développement veut que son fichier de conf puisse être généré par un écosystème large et intégré dans un workflow (flux de travail :)) unifié et la, le XML à sa place (et je ne veux voir personne crier foutaise !) :)
        • [^] # Re: XML et GUI ?

          Posté par (page perso) . Évalué à 5.

          foutaises !
          cf. Business_loto
        • [^] # Re: XML et GUI ?

          Posté par . Évalué à 1.

          Tu mets le doigt sur un point qui justement penche en défaveur de XML.

          Déjà :

          arbre {
          branche {
          fruit {
          }
          fruit {
          }
          branche {
          fruit
          }
          }
          }

          C'est déjà moins verbeux que :




          <fruit .... />
          <fruit ... />


          <fruits ... />
          <fruits ... />




          Et la c'est un exemple tout simple.
          C'est plus parce que l'équipe de développement veut que son fichier de conf puisse être généré par un écosystème large et intégré dans un workflow (flux de travail :)) unifié et la, le XML à sa place (et je ne veux voir personne crier foutaise !) :)
          Explique-moi ce que vient faire la conf d'un système dans un workflow.
          • [^] # Re: XML et GUI ?

            Posté par . Évalué à 3.

            GRRRR! Mon commentaire n'est pas passé comme il le faut :(.
          • [^] # Re: XML et GUI ?

            Posté par . Évalué à 2.

            Ton exemple est moins verbeux, mais on ne gagne pas beaucoup de caractère non plus, par contre, on perd en lisibilité à mon gout. Si le but est de gagner des caractères, je peut faire un fichier binaire que l'on éditerait avec un outil que l'on appellerait... regedit :)

            Explique-moi ce que vient faire la conf d'un système dans un workflow. La conf d'un système peut faire (voir même fait partie) partie d'un workflow !
          • [^] # Re: XML et GUI ?

            Posté par . Évalué à 3.

            Bon je reprends ...
            arbre {
            branche {
            fruit {
            }
            fruit {
            }
            branche {
            fruit
            }
            }
            }

            <arbre>
            <branches>
            <fruit ... />
            <fruit ... />
            </branche>
            <branche>
            <fruit ... />
            </branches>
            </arbre>

            Et si on parle de lisibilité :
            <arbre><branches><fruit ... /><fruit ... /></branche><branche>
            <fruit ... /></branches></arbre>


            le <branches> ... </branches> est volontaire : c'est ce qu'on rencontre dans RedHAt Cluster avec les balises <clusternodes> <node></node></clusternodes>

            Et pour la longueur :

            <Supercalifragilisticexpialidocious>
            <balise1>.....</balise1>
            </Supercalifragilisticexpialidocious>

            Supercalifragilisticexpialidocious {
            balise1{ ... }
            }
            • [^] # Re: XML et GUI ?

              Posté par . Évalué à 4.

              après ya xml et xml... c'est certain que si on se borne à imbriquer des balises sans attributs on va pas aller loin... par contre si on utilise intelligemment les attributs, ça peut être super lisible du xml... encore faut-il savoir l'utiliser correctement...
              • [^] # Re: XML et GUI ?

                Posté par . Évalué à 2.

                Je n'ao pas mis d'attributs expres, le fait qu'il y en ait ne change pas grand chose dans les deux cas.
                • [^] # Re: XML et GUI ?

                  Posté par . Évalué à 5.

                  si ça change beaucoup de choses !

                  on a souvent, par manque de connaissances ou par souci de simplicité pour le parsing, ce genre de truc immonde :


                  <tartes>
                  <nombre>2</nombre>
                  <tarte>
                  <nom>Aux pommes</nom>
                  <taille>1</taille>
                  <prix>3</prix>
                  </tarte>
                  <tarte>
                  <nom>Au shmulbluck</nom>
                  <taille>2</taille>
                  <prix>30</prix>
                  </tarte>
                  </tartes>

                  Alors que

                  <tartes nombre="2">
                  <tarte nom="Aux pommes" taille="1" prix="3" />
                  <tarte nom="Au shmulbluck" taille="2" prix="30" />
                  </tartes>

                  est beaucoup plus lisible, simple à maintenir presque auto-documenté si on choisit bien ses noms d'attributs et moins lourd au final... sans parler du fait que si on aligne les attributs (avec des tabs) la recherche (grep avec les yeux) est facilitée !

                  • [^] # Re: XML et GUI ?

                    Posté par . Évalué à 2.

                    oui mais en pratique j'ai vupeu de fichiers aussi bien faits pour des confs de soft. L'exemple Redhat Cluster encore : lorsque je définis une ressource via l'interface graphique :


                    <failoverdomains/>

                    <ip address="aaa.bbb.ccc.ddd" monitor_link="1"/>



                    Qu'est-ce que ce rm ? De plus je ne vois rien d'auto-documenté dedans. Les seuls fichiers xml propres que je vois, ce sont ceux qui sont standardisés (svg par exemple ou c'est reativement clair et propre).

                    Imagine dans l'exemple que tu as donné, qu'on remplace "tarte" par Trt, prix par prx, taille par t, .... Celàdit, ce n'est pas un problème d'XML, un autre format serait tout aussi confus. Sinon, si on prend l'exemple style ipf :

                    1 tarte pommes taille 1 prix 3
                    1 tarte shmulbluck taille 2 prix 30
                    • [^] # Re: XML et GUI ?

                      Posté par . Évalué à 2.

                      Je ne m'y ferais jamais à ces balises :

                      <rm>
                      <failoverdomains/>
                      <resources>
                      <ip address="aaa.bbb.ccc.ddd" monitor_link="1"/>
                      </resources>
                      </rm>
                      • [^] # Re: XML et GUI ?

                        Posté par . Évalué à 2.

                        rm = ressource manager non?
                        Ce que je comprends c'est que ton ressource manager manage l'ip aaa.bbb.machin, avec un monitor link, et qu'il n'y a pas de domain de failover.

                        Note: je sais meme pas ce que ton red hat cluster fait.

                        Sinon comme dit plus haut, ca serait pareil avec un fichier de conf a plat, si les noms ne veulent rien dire, ils ne veulent rien dire...
                      • [^] # Re: XML et GUI ?

                        Posté par . Évalué à 4.

                        Quel rapport entre le nommage des balises et le fait que ce soit du Xml ou pas ? Si ça avait été :

                        rm {
                            failoverdomains: '',
                            resources: {
                                ip {
                                    address: 'aaa.bbb.ccc.ddd',
                                    monitok_link: 1
                                }
                            }
                        }


                        est-ce que ça te dit plus ce que veut dire "rm" ?
                        • [^] # Re: XML et GUI ?

                          Posté par . Évalué à 2.

                          C'est vrai que je mélange un peu tout .... Il y a 3 problèmes pour moi :

                          - conf en xml
                          - manque de documentation du fichier de conf
                          - obligation de passer par l'interface graphique si on veut savoir à quoi correspondent les diverses options du fichier de conf.

                          Je suis d'accord avec toi: si le nom est mal choisi, que ce soit en XML ou pas ça ne change pas grand chose (et rm je l'ai deviné aussi, c'était juste pour l'exemple). Cependant, je remarque en général que les outils dont le fichier de conf n'est pas XML ont tendance à documenter ledit fichier de conf dans une page man par exemple ou quelque part ailleurs.
                    • [^] # Re: XML et GUI ?

                      Posté par (page perso) . Évalué à 3.

                      oui mais en pratique j'ai vupeu de fichiers aussi bien faits pour des confs de soft.

                      Donc tu râle surtout contre les fichiers de confs mal fait. (et ça c'est indépendant du langage).

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: XML et GUI ?

                        Posté par . Évalué à 2.

                        Ben disons que c'est plus facile de mal faire un fichier de conf en xml : tout simplement parce pour certains, c'est parce que c'est du XML que c'est bien. Et l'auto-documentation ça me fait bien rire.
                    • [^] # Re: XML et GUI ?

                      Posté par . Évalué à 2.

                      oui mais en pratique j'ai vupeu de fichiers aussi bien faits pour des confs de soft.

                      c'est ce que je dis, ya xml et xml... et même en utilisant des attributs correctement, il est rare d'avoir des noms de d'attributs évocateurs... quand ils ne sont pas en japonais ou russe... (oui oui j'ai vu ça) même chose dans certains softs qui utilisent des bases de données où les noms de table et de champs sont des plus abscons ou parfois les valeurs sont de gros blobs ou carrément des dumps de tableaux voire du php ou autres joyeusetés....
        • [^] # Commentaire supprimé

          Posté par . Évalué à 4.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: XML et GUI ?

            Posté par . Évalué à 3.

            un autre exemple qui m'est venu à l'esprit :
            -ipf/pf :
            * par ligne
            * très lisible et très facilement éditable
            • [^] # Re: XML et GUI ?

              Posté par (page perso) . Évalué à 3.

              Normal, tout comme le smtpd issu de OpenBSD le format de conf à suivi un processus de maturation nourrie au KISS.
    • [^] # Re: XML et GUI ?

      Posté par (page perso) . Évalué à 6.

      Pourquoi les développeurs font des GUI ?
      Parce que ça permet de faire des choses basique sans avoir aucune compétence ou presque, et sans "perdre" de temps à faire un man appli. C'est bien ou pas ? Ce n'est pas à moi de le dire ! En tout cas, ce n'est pas mes interfaces graphiques qui t'embêterons, je n'en fait pas, ça me fait trop ch### :)


      Sauf que le monsieur se plaint des GUI exclusives pour les applis serveur. Applis destinées à des utilisateurs qui sont censés avoir quelques compétences, qui peuvent prendre le temps de faire "man appli" parce qu'ils savent que ce temps sera regagné au centuple s'ils utilisent ladite appli plus d'une fois. Et, comme mentionné, applis qui sont également destinées à être utilisées sur des machines qui n'ont pas forcément X.

      Donc le coup de gueule du monsieur est complètement justifié.
      • [^] # Re: XML et GUI ?

        Posté par . Évalué à 3.

        Sauf que le monsieur se plaint des GUI exclusives pour les applis serveur. Applis destinées à des utilisateurs qui sont censés avoir quelques compétences, En théorie...

        En pratique, le clicka-convi rebute moins le mec qui à été propulsé expert en "techno toute nouvelle qui rapporte". Je viens du monde BSD ou les GUI sont rare voir quasi inexistante (au pire en ncurse), alors tu pense bien que les GUI, c'est pas ma tasse de thé, c'est pas scriptable, duplicable, etc... MAIS, pour notre nouvelle expert, entre :
        savoir qu'il faut, dans asterisk, dans extension.conf, ajouter dans toutes les extensions appelant de MeetMe l'option "o" pour activer la reduction de bruit des conférences
        ou (exemple d'une GUI que j'invente la tout de suite) :
        sélectionner les conférences
        faire un click droit => propriétés => cocher "activer la réduction de bruit"
        notre nouvel expert choisi la GUI, et c'est indéniablement plus parlant et intuitif.
        Mais par contre, il ne pourra pas (comme on le fait ici) créer des conférences à la volé etc parce c'est scripté et intégré dans l'intranet de la boite.
        • [^] # Re: XML et GUI ?

          Posté par (page perso) . Évalué à 1.

          Déjà rien n'empêche de mettre une GUI au-dessus d'un fichier de conf qui n'a pas une arborescence de profondeur qui tend vers +∞.

          Ensuite, si on donnait aux gens les moyens de faire correctement le boulot qu'on leur demande de faire, on en serait pas là. Un patron qui ne préserve pas l'employabilité de ses collaborateurs est un mauvais patron (ok j'avoue, je sors d'un cours de «loto businessmanagement et gestion de l'entreprise») qui mérite d'être lapidé en place public (ok faut encore que je revois le cours pour me bourrer le mou de main invisible).
  • # Outils en CLI

    Posté par . Évalué à 3.

    Ça m'étonnait, alors j'ai fait une recherche google, et j'ai trouvé ce lien :
    http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/(...)

    Ils ont un outils en ligne de commande pour manipuler la config, seulement c'est pas un éditeur de texte. A toi de dire si ça te convient ...
  • # GLMF est d'accord avec toi

    Posté par (page perso) . Évalué à 3.

    Y avait une complainte semblable de Denis Bodor dans l'édito de GNU/Linux Magazine N°121 :
    http://www.gnulinuxmag.com/index.php/2009/10/30/edito-gnulin(...)
  • # Règle du KISS et XML

    Posté par . Évalué à 2.

    Salut,

    AMHA tu te poses les bonnes questions et tu te donnes de mauvaises réponses.

    Le fichier de conf en XML a beaucoup d'avantages (Encodage, xquery, accessibilité en ligne, publication) et peu d'inconvénients (taille du fichier).
    Si tu dois créer des config pour un client qui a son serveur sous windows avec de l'iso-8859-5 et que tu prépares sa config sur un serveur linux avec de l'utf-8 tu apprécieras (iconv çà va 5 minutes).

    "il est impossible de le configurer via ligne de commande" : nano, vi, emacs, sed, ed sont tes amis.

    Tu peux être amené à créer des configs pour des serveurs pour lesquels tu n'as pas (de carte graphique, tout à fait d'accord, mais aussi) pas de term, juste un login/password ftp.

    Bon courage avec le XML, la tendance ne va pas s'inverser.

    http://www.ibm.com/developerworks/xml/library/x-tengoodxmlha(...)

    Enzo Bricolo

    ps1 : "64 caractères devraient être suffisants pour tout le monde"

    ps2 : Tant qu'on y est, tu peux aussi utiliser un navigateur (même en ligne de commande) qui te proposera la correction orthographique et grammaticale.
    • [^] # Re: Règle du KISS et XML

      Posté par . Évalué à 2.

      Le fichier de conf en XML a beaucoup d'avantages (Encodage, xquery, accessibilité en ligne, publication) et peu d'inconvénients (taille du fichier).
      Non, XML est verbeux et ne sert à RIEN pour un fichier de conf. Ce n'est facile QUE pour le développeur.
      Si tu dois créer des config pour un client qui a son serveur sous windows avec de l'iso-8859-5 et que tu prépares sa config sur un serveur linux avec de l'utf-8 tu apprécieras (iconv çà va 5 minutes).
      Tu peux développer STP ? Parce que je ne vois pas en quoi XML apporte quelque chose.
      • [^] # Re: Règle du KISS et XML

        Posté par . Évalué à 7.

        Non, XML est verbeux et ne sert à RIEN pour un fichier de conf. Ce n'est facile QUE pour le développeur.

        Si c'est ecrit en majuscule, c'est que ca doit etre VRAI.

        Le fait que tu n'en voit pas l'utilite ne veut pas dire que c'est inutile pour tout le monde.

        Sinon pour la lecture/modification, tu n'as qu'a utiliser un editeur potable qui te presente ca sous forme d'arborescence avec juste clef/(attributs)/valeur.
        Comme ca, tu ne vois meme pas les balises verbeuses et c'est comme si tu manipulais une structure arborescente.
        • [^] # Re: Règle du KISS et XML

          Posté par . Évalué à 5.

          Oui, et tu en connais un bon en mode texte ? De préférence qui soitinstallé par défaut dans les distribs car il est interdit sur une machine de prod d'ajouter comme on veut ce genre de soft.
          • [^] # Re: Règle du KISS et XML

            Posté par . Évalué à 2.

            ah ah ah, et tu édites directement un fichier de conf sur une machine de prod, comme ça, en live ?

            y'en a qui ont essayé, ils ont eu des problèmes. cela dit, c'est rapide...
            • [^] # Re: Règle du KISS et XML

              Posté par . Évalué à 2.

              Tu cherches la bête ou il ne faut pas. LA machine n'est pas encore en prod. Et ça ne change rien au problème initial.
            • [^] # Re: Règle du KISS et XML

              Posté par (page perso) . Évalué à 2.

              Voyons pour un usage qui reste dans le cadre de la ligne de commande :
              * ~/.aspell.fr.prepl
              * ~/.vimrc,
              * ~/.ssh/*
              * ~/.bazshrc

              Même sur ta machine en prod tu as le droit de configurer les outils dont tu te sers, non ?

              M'enfin si toi tu préférais qu'ils soient en xml…
        • [^] # Re: Règle du KISS et XML

          Posté par . Évalué à 5.

          Si c'est ecrit en majuscule, c'est que ca doit etre VRAI.
          C'est surtout queje me suis laissé emporter par le côté trollesque du débat (ce n'était pas mon intention initiale) et un peu d'énervement (regarde l'heure à laquelle j'ai posté).

          Sinon pour la lecture/modification, tu n'as qu'a utiliser un editeur potable qui te presente ca sous forme d'arborescence avec juste clef/(attributs)/valeur.
          Comme ca, tu ne vois meme pas les balises verbeuses et c'est comme si tu manipulais une structure arborescente.


          Je veux bien, mais en connais-tu un bon sachant que :

          - je n'ai pas de poste d'admin Linux/Redhat (officiel)
          - je ne peux pas installer ça sur mon serveur
          - je ne peux pas déporter l'affichage X de façon simple.

          Ces contraintes ne sont pas un choix de ma part, elles me sont imposées par le contexte de travail.
          • [^] # Re: Règle du KISS et XML

            Posté par (page perso) . Évalué à 1.

            je suis à peu prêt certain qu'il existe des plugins pour vim/emacs, qui te permettent de charger des schémas de fichiers xml ( schémas qui sont super simple à faire en relaxng par ex), et donc d'avoir, Ô magie, la complétion automatique.


            IMHO, l'argument "le XML c'est trop verbeux" etc ou "trop chiant à écrire", ne tient pas. Tout éditeur de nos jours sait gérer le XML, même sans le support de schemas.
      • [^] # Re: Règle du KISS et XML

        Posté par . Évalué à 1.

        <?xml version="1.0" encoding="iso-8859-5" ?>

        Y'a un truc bien marqué encoding, c'est pratique.
        Et les fin de ligne LF ou CRLF, tu t'en bats l'oeil en XML.

        Ensuite, y'a surement d'autres paradigmes plus efficaces, mais le XML est AMHA mieux que de l'ASCII pourrave encodé en windows 1252 "parce-que-c'est-le-standard", autrement dit mon quotidien chez les clients.
        • [^] # Re: Règle du KISS et XML

          Posté par . Évalué à 2.

          Je l'admets, c'est un argument qui facilite la vie, mais pour ma part je trouve qu'il ne compense pas les autres arguments.
          • [^] # Re: Règle du KISS et XML

            Posté par . Évalué à 2.

            J'écris vraiment n'importe quoi en e moment ... Désolé, besoin de vacances ... Je reprends :

            "Je l'admets, c'est un argument qui facilite la vie, mais pour ma part je trouve qu'il ne compense pas les autres inconvénients "
        • [^] # Commentaire supprimé

          Posté par . Évalué à 2.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Règle du KISS et XML

            Posté par . Évalué à 0.

            Ben dans un fichier de config, il est tout a fait possible que tu definisse le nom de qq chose.
            Et le nom de ce qq chose, il peut etre en mandarin oriental.
            Tu commences a le voir l'interet de l'utf8?

            Apres, si les gens qui editent le xml pensent faire du 8859 et t'envoie de l'utf8... ben faut t'attendre a d'autres coups fourres de leur part, et ils auraient tout a fait ete capable de t'envoyer un fichier en windows 1252 blinde de crlf ou autre joyeusetes.
            • [^] # Commentaire supprimé

              Posté par . Évalué à 1.

              Ce commentaire a été supprimé par l'équipe de modération.

              • [^] # Re: Règle du KISS et XML

                Posté par . Évalué à 0.

                heuuu
                <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://java.sun.com/xml/ns/javaee"
                xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
                xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
                id="WebApp_ID"
                version="2.5">

                <display-name>Calendrier des employés</display-name>
                <description>Cette application permet aux employés à leur calendrier de façon unifiée</description>
                ... un gros paquet de trucs ...
                </web-app>

                si ca c'est pas de la config, je sais pas ce que c'est...
                • [^] # Re: Règle du KISS et XML

                  Posté par . Évalué à 1.

                  Un mélange immonde entre de la conf et des données ?
                  • [^] # Re: Règle du KISS et XML

                    Posté par . Évalué à 1.

                    ha.
                    Alors, peut tu nous explique nous comment tu ferais un truc qui soit pas immonde?
                    • [^] # Re: Règle du KISS et XML

                      Posté par . Évalué à 1.

                      En laissant à l'application le soin de ranger elle même les données qu'on lui confie, elle devrait fournir une interface pour les modifier.

                      Pour moi ça n'a pas l'air à première vu de modifier des options de configuration (comprendre : qui changent de manière plus ou moins subtile son comportement), ce sont bel et bien des données que l'on fournit au programme pour qu'il fonctionne, des informations sur une webapp ici visiblement, et je ne crois pas que le fait de fournir la description de cette dernière ait la moindre influence sur la façon dont elle sera exécutée.

                      Après c'est juste ma façon de voir les choses \o
                      • [^] # Re: Règle du KISS et XML

                        Posté par . Évalué à 0.

                        Tu bottes en touche la, tu ne fais que repousser le probleme: va bien falloir mettre des caracters accentues a un moment, et totof2000 va venir gueuler que c'est du xml kipu, d'une part.

                        D'autre part, ta definition de configuration est stricte et tres theorique, mais je la trouve assez douteuse. Dans le cas qui nous concerne, je considere le display name comme une config de la web app, clairement pas comme une donnee.
                        C'est un point de vue, certes, je concois qu'il se discute, mais la ligne n'est surement pas aussi tranchee que tu a l'air de le pretendre.

                        J'ai prit le premier truc localizable que j'ai trouve, c'etait ca.
                        On peut prendre la welcome file list, qui est un fichier, et vient pas me dire que celui la peut pas etre accentue.
                        Je suis entierement d'accord que c'est pas la meilleur des pratiques, mais c'est quelque chose de faisable.
                        • [^] # Re: Règle du KISS et XML

                          Posté par . Évalué à 1.

                          Tu bottes en touche la, tu ne fais que repousser le probleme: va bien falloir mettre des caracters accentues a un moment, et totof2000 va venir gueuler que c'est du xml kipu, d'une part.

                          Heureusement que le XML n'est pas la seule manière de conserver des données localisées !
                          Tu semble oublier que le problème n'est pas le fait que les informations soient stockées en XML, c'est juste qu'il faille modifier ledit XML soi-même.
                          Quand je vois mes HAL policies j'ai envie de pleurer... (et surtout pas la moindre envie d'y toucher)
        • [^] # Re: Règle du KISS et XML

          Posté par . Évalué à 6.

          Rajoutes par dessus la definition stricte d'une palanquee de trucs bien utiles (commentaires, encodage de caracteres speciaux, namespaces, ref), la definition claire de quoi faire en quoi d'erreur syntaxique, la definition tres claire de ce qui est une erreur, bref une vraie spec' d'une structure de donnees.

          Le fait que ca soit un langage a balise, ou cle/valeur ou autre chose, dans le fond c'est pas ca qui est vraiment important, ce qui est important c'est que le format est clairement documente et que tout le monde connait (ou devrait la connaitre en tout cas) cette doc.

          Rajoutes encore par dessus l'ecosysteme autour d'xml ou tu peux trouver une palanquee d'outil a tous les niveaux pour n'importe quelle plateforme, ca commence a en faire des avantages, au prix de qq kilo octets de disque, ca commence a etre interessant.

          C'est ca qui en fait un truc adapte a un fichier de conf.
          • [^] # Re: Règle du KISS et XML

            Posté par (page perso) . Évalué à 1.

            Voila des arguments pertinents.

            Le fait est qu'un format en langage clef/valeur est plus pratique pour l'édition manuel et que dans le même temps l'imbrication que permet le XML est souvent complètement inutile pour un fichier de conf (ou pire incite à complexifier un fichier dont la structure pourrait rester simple !).

            Donc l'idéal serait qu'on ai un format de fichier en format clef/valeur aussi bien documenté et réfléchie que le XML, et que les développeurs l'adoptent dans les situations ou il est plus pertinent que le xml.

            Mais qu'attendons-nous ? :)
            • [^] # Re: Règle du KISS et XML

              Posté par (page perso) . Évalué à 2.

              En gros, tu veux du XML limité à +/- 3 niveaux. Et bien tu prend du XML et tu fais pas n'importe quoi avec.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Règle du KISS et XML

                Posté par (page perso) . Évalué à 2.

                Ça ne correspond pas à ce que j'ai dit.

                Si le xml c'était tellement de la balle, on aurait pas de syntax wiki, smtpd.conf[1], etc. Si il y a la moindre chance que l'utilisateur (quelque soit son niveau) ai à modifier le fichier avec un éditeur de texte, alors xml est un mauvais choix.

                Ça ne veut pas dire qu'un fichier texte clef/valeur est nécessairement mieux qu'un xml bien sûr.

                Qu'est ce que tu préfères avoir à éditer, honnètement :

                {{à sourcer|date=octobre 2007}}

                {{Infobox Site web
                | nom = Linuxfr
                | favicon =
                | logo = Image:Linuxfr.png
                | image =
                | description = actualité du [[logiciel libre]]
                | url = [http://linuxfr.org/ linuxfr.org]
                | commercial =
                | type = actualité communautaire
                | langue = [[français]]
                | inscription = facultative
                | propriétaire = association Linuxfr
                | auteur =
                | date de lancement = {{Date|28|juin|1998}}
                | état actuel =
                | revenue =
                }}
                '''Linuxfr.org''' est un site francophone communautaire traitant de l'actualité informatique liée le plus souvent au [[logiciel libre]]. Il est alimenté par sa communauté d'utilisateurs en mode contributif.

                Ce site est également parfois appelé '''Da Linux French Page''' ou simplement '''DLFP'''.

                == Services ==
                === Dépêches ===
                Des dépêches dont les sujets tournent autour du logiciel libre et de la culture libre sont publiées irrégulièrement plusieurs fois par jour en moyenne, selon l'actualité, les contributions et la charge de modération. Il existe trois « types » de dépêches : la dépêche phare qui reste épinglée en haut de page, les dépêches de « première page » affichées en pleine page qui sont jugées importantes et les dépêches de « seconde page » qui sont partiellement affichées dans la colonne de gauche.








                Logo de Linuxfr





                URL
                linuxfr.org


                Description
                actualité du logiciel libre


                Type de site
                actualité communautaire


                Langue(s)
                français


                Inscription
                facultative


                Propriétaire
                association Linuxfr


                Lancement
                28 juin 1998


                modifier 


                Linuxfr.org est un site francophone communautaire traitant de l'actualité informatique liée le plus souvent au logiciel libre. Il est alimenté par sa communauté d'utilisateurs en mode contributif.
                Ce site est également parfois appelé Da Linux French Page ou simplement DLFP.







                [modifier] Services
                [modifier] Dépêches
                Des dépêches dont les sujets tournent autour du logiciel libre et de la culture libre sont publiées irrégulièrement plusieurs fois par jour en moyenne, selon l'actualité, les contributions et la charge de modération. Il existe trois « types » de dépêches : la dépêche phare qui reste épinglée en haut de page, les dépêches de « première page » affichées en pleine page qui sont jugées importantes et les dépêches de « seconde page » qui sont partiellement affichées dans la colonne de gauche.
                Les auteurs de dépêches sont des contributeurs authentifiés ou anonymes. Ces dépêches sont modérées, vérifiées, amendées ou étoffées, et éventuellement publiées par une équipe dédiée.


                Ah bah zut ça passe même pas les balises xml. Encore un avantage pratique d'un format non balisé!

                [1] http://www.openbsd.org/cgi-bin/man.cgi?query=smtpd.conf&(...)
                • [^] # Re: Règle du KISS et XML

                  Posté par (page perso) . Évalué à 2.

                  Il faut choisir texte sans html, sinon c'est interpréter comme du code

                  Mais je pense que ton fichier xml a pas l'air optimal, il n'a pas l'air d'utiliser les attributs (mais c'est difficile à dire sans les balises)

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Règle du KISS et XML

          Posté par (page perso) . Évalué à 1.

          Tiré de http://txt2tags.sourceforge.net/sample.t2t :

          %!encoding: iso-8859-1


          C'est pourtant pas du xml.

          Donc c'est pas vraiment un argument valable pour l'utilisation systématique de xml pour faire un fichier de conf.
    • [^] # Re: Règle du KISS et XML

      Posté par . Évalué à 3.

      Tu peux être amené à créer des configs pour des serveurs pour lesquels tu n'as pas (de carte graphique, tout à fait d'accord, mais aussi) pas de term, juste un login/password ftp.
      Das le cas d'un cluster, ou même d'un serveur (je pense à l'usine a gaz d'arrêt/relance de services sous Solaris censé remplacer init.d), si tu n'as pas un accès shell à ta machine, un accès ftp ne sert à rien.

      Sérieusement je conçois que pour certaines choses, XML est bien pratique, mais dans le cas d'un service qui touche à l'administration de la machine, c'est n'importe quoi.
      • [^] # Re: Règle du KISS et XML

        Posté par . Évalué à 7.

        Voyons voir, imagine le scenario suivant:
        - tes fichiers de confs sont geres de facon centralisee (genre dans un repository git)
        - une partie de ces fichiers doivent etre crees/modifies par des utilisateurs, qui ne veulent pas/savent pas le faire a la main et donc tu as une gui/page web avec une moulinette derriere qui te sort un fichier de conf
        - tu veux pouvoir valider tes fichiers de confs avant deployment pour etre sur que ca va pas te peter a la gueule a cause d'une virgule oubliee quelque part.

        Avec du XML partout, tu sors simplement un fichier XML de ta moulinette, tu peux relire trivialement la conf et meme construire a la volee ta GUI a partir de la conf. Pour valider, une DTD ou un schema et hop, la majorite du boulot de fait.

        Maintenant, la meme chose avec des fichiers dans un format specifique pour chaque appli, ca veut dire ecrire (ou extraire du code de l'appli) un parseur/serialiseur pour chaque fichier de conf que tu veux generer/relire, faire la GUI entierement a la main (ou ecrire un generateur par fichier de conf different) et pour la validation c'est pareil, faut tout te taper a la main.

        Donc voila, on a compris que pour ton utilisation ca ne te sert a rien ou ca ne t'interesse pas, mais il y a plein de gens qui sont contents d'avoir ca en XML pour l'integrer facilement a leur workflow.
        • [^] # Re: Règle du KISS et XML

          Posté par . Évalué à 2.

          Ta situation n’est pas une situation de tous les jours, et tu seras de toute manière forcé de faire du développement spécifique. À partir de là, tu peux parfaitement faire tout ton système intermédiaire en XML et sortir la conf validée dans un autre format. L’avantage ? Les 2% d’utilisateurs qui ont besoins de choses compliquées utilisent un format compliqué sans embêter les autres qui préfèrent garder quelque chose de simple.

          Hard cases make bad laws.
    • [^] # Re: Règle du KISS et XML

      Posté par . Évalué à -2.


      Le fichier de conf en XML a beaucoup d'avantages (Encodage, xquery, accessibilité en ligne, publication) et peu d'inconvénients (taille du fichier).
      Si tu dois créer des config pour un client qui a son serveur sous windows avec de l'iso-8859-5 et que tu prépares sa config sur un serveur linux avec de l'utf-8 tu apprécieras (iconv çà va 5 minutes).


      http://vimdoc.sourceforge.net/htmldoc/mbyte.html

      Supported 'encoding' values are: *encoding-values*
      1 latin1 8-bit characters (ISO 8859-1)
      1 iso-8859-n ISO_8859 variant (n = 2 to 15)
      1 koi8-r Russian
      1 koi8-u Ukrainian
      1 macroman MacRoman (Macintosh encoding)
      1 8bit-{name} any 8-bit encoding (Vim specific name)
      1 cp437 similar to iso-8859-1
      1 cp737 similar to iso-8859-7
      1 cp775 Baltic
      1 cp850 similar to iso-8859-4
      1 cp852 similar to iso-8859-1
      1 cp855 similar to iso-8859-2
      1 cp857 similar to iso-8859-5
      1 cp860 similar to iso-8859-9
      1 cp861 similar to iso-8859-1
      1 cp862 similar to iso-8859-1
      1 cp863 similar to iso-8859-8
      1 cp865 similar to iso-8859-1
      1 cp866 similar to iso-8859-5
      1 cp869 similar to iso-8859-7
      1 cp874 Thai
      1 cp1250 Czech, Polish, etc.
      1 cp1251 Cyrillic
      1 cp1253 Greek
      1 cp1254 Turkish
      1 cp1255 Hebrew
      1 cp1256 Arabic
      1 cp1257 Baltic
      1 cp1258 Vietnamese
      1 cp{number} MS-Windows: any installed single-byte codepage
      2 cp932 Japanese (Windows only)
      2 euc-jp Japanese (Unix only)
      2 sjis Japanese (Unix only)
      2 cp949 Korean (Unix and Windows)
      2 euc-kr Korean (Unix only)
      2 cp936 simplified Chinese (Windows only)
      2 euc-cn simplified Chinese (Unix only)
      2 cp950 traditional Chinese (on Unix alias for big5)
      2 big5 traditional Chinese (on Windows alias for cp950)
      2 euc-tw traditional Chinese (Unix only)
      2 2byte-{name} Unix: any double-byte encoding (Vim specific name)
      2 cp{number} MS-Windows: any installed double-byte codepage
      u utf-8 32 bit UTF-8 encoded Unicode (ISO/IEC 10646-1)
      u ucs-2 16 bit UCS-2 encoded Unicode (ISO/IEC 10646-1)
      u ucs-2le like ucs-2, little endian
      u utf-16 ucs-2 extended with double-words for more characters
      u utf-16le like utf-16, little endian
      u ucs-4 32 bit UCS-4 encoded Unicode (ISO/IEC 10646-1)
      u ucs-4le like ucs-4, little endian
      • [^] # Re: Règle du KISS et XML

        Posté par . Évalué à 1.

        Oh, on a affaire a un vrai!

        Tu peux nous faire un copier-coller des encodages supportes par emacs aussi, histoire de completer?

        Hint: t'es a cote de la plaque (mais c'est pas grave, continue).
        • [^] # Re: Règle du KISS et XML

          Posté par . Évalué à 2.

          Bon, je reconnais que je me suis laissé emporter par le côté trollesque du débat. Celà dit, peux-tu STP m'expliquer en quoi je suis à côté de la plaque ? Personnellement je ne demande qu'à être convaincu, XML, j'aime bien, entre autre c'est pratique notamment pour générer à la volée des petits schémas. Pour des fichiers de conf, je ne suis pas vraiment convaincus par les arguments qui ont été donnés ici.
          • [^] # Re: Règle du KISS et XML

            Posté par (page perso) . Évalué à 2.

            l'interet du XML, c'est que l'encodage est en principe indiqué dans l'entete xml, et fait partie de la spec. Autrement dit, les outils qui brassent du xml savent gérer son contenu sans problème d'encodage.

            Ce n'est pas le cas des fichiers de conf plain/text. À moins qu'il y ait un caractère BOM qui permet de reconnaitre de l'utf-8 (caractère qui n'est pas toujours bien supporté, surtout par les applis qui lisent les fichiers de conf), l'application, et voir même l'éditeur, ne peuvent deviner le charset utilisé (ou se trompe une fois sur deux, la divination d'un charset n'étant pas une science exacte).

            Alors ok, tu peux choisir le charset dans un éditeur. Mais encore faut-il que tu saches, TOI, avec quel charset le fichier a été enregistré. Même si il y a beaucoup de chance, dans nos contrées, pour que ce soit de l'utf-8 ou de l'iso-8859-1(5).
            • [^] # Re: Règle du KISS et XML

              Posté par . Évalué à -1.

              rhaaa mais pourquoi vous parlez tous d'encodage au lieu de codage ?
              De grâce messieurs, on parle de codage en bon français (codage de Huffman, codage préfixe, codeur/décodeur = codec, message codé, etc.)
            • [^] # Re: Règle du KISS et XML

              Posté par . Évalué à 2.

              Alors ok, tu peux choisir le charset dans un éditeur. Mais encore faut-il que tu saches, TOI, avec quel charset le fichier a été enregistré. Même si il y a beaucoup de chance, dans nos contrées, pour que ce soit de l'utf-8 ou de l'iso-8859-1(5).
              Ben disons que pour un fichier de conf système, si je ne sais pas avec quel charset j'enregistre le fichier ... ou si je ne suis pas capable de spécifier au framework que j'utilise le charset du fichier de conf à générer, ya comme un problème.
              • [^] # Re: Règle du KISS et XML

                Posté par . Évalué à 1.

                le probleme n'est pas pour celui qui ecrit le document, mais celui qui le lit.
                Celui qui l'ecrit, on se doute qu'il connait le charset, vu qu'il l'a genere.
                Celui qui le lit, il faut qu'il le devine.
                Quand c'est un humain, on peut lui faire confiance (quoique...), quand c'est une machine, ca a une chance sur deux de foirer.

                Typiquement, un fichier de conf recupere sur internet encode utf8 quand t'es en 8859, ou n'importe quel autre combinaison qui fait apparaitre des caracteres douteux.

                Ta remarque montre bien ton manque de recul: tu restes cantonne au cas bien gentillet ou c'est toi qui ecrit le document pour toi sur ta machine.
                C'est sur que quand tout va bien, ton fichier properties en ascii, il fait parfaitement l'affaire.
                Quand les choses se compliquent un peu, xml propose des solutions au problemes, la ou il faut les inventer pour les fichier properties.

                En clair? On commence a rajouter des trucs complexes a un truc simple (genre les horreurs style #! encoding utf8, les \ pour faire des valeurs multilignes et tout le tralala).

                L'interet du xml est justement une bonne spec qui resoud tous ces problemes. Tu peux reinventer la roue, en version ovale qui plus est, mais c'est dommage quand meme, non?
                • [^] # Re: Règle du KISS et XML

                  Posté par (page perso) . Évalué à 4.

                  Bah non, parce que si tu veux des roues avec un pneu que tu peux facilement changer à la main, tu veux pas des roues avec chenilles de char d'assaut qui sont censés résister à tout mais qu'il faut surtout pas avoir envie de changer à la main.
                • [^] # Re: Règle du KISS et XML

                  Posté par . Évalué à 1.

                  En principe un fichier de XML c'est en UTF-8, en tous cas c'est l'usage le plus courant et ça a été la transition ces dernières années.

                  Le BOM ( Byte_Order_Mark ) n'est pas tout à fait standard et je ne crois pas qu'on l'utilise sous Linux.

                  Pour un fichier de conf système habituel, c'est souvent en ASCII (US) ou en Latin.
                • [^] # Re: Règle du KISS et XML

                  Posté par . Évalué à 1.

                  Typiquement, un fichier de conf recupere sur internet encode utf8 quand t'es en 8859, ou n'importe quel autre combinaison qui fait apparaitre des caracteres douteux.
                  Yen a qui me raillaient parce que je modifie un fichier de conf sur un serveur de prod .... mais récupérer un fichier de conf sur internet ... HUM !
                  a remarque montre bien ton manque de recul: tu restes cantonne au cas bien gentillet ou c'est toi qui ecrit le document pour toi sur ta machine.
                  C'est sur que quand tout va bien, ton fichier properties en ascii, il fait parfaitement l'affaire.

                  Quoi que tu en dises, c'est souvent le cas quand je mets un serveur en prod : jamais je ne récupère un fichier sur internet.
                  L'interet du xml est justement une bonne spec qui resoud tous ces problemes. Tu peux reinventer la roue, en version ovale qui plus est, mais c'est dommage quand meme, non?
                  Non : la ce que je ois c'est qu'XML n'apporte rien à ce qu'on savait faire jusqu'à ce jour.
    • [^] # Re: Règle du KISS et XML

      Posté par . Évalué à 3.

      xmlstar sinon, pour un équivalent à sed (ou grep, ou autre) en version XML, donc en profitant de la structure hiérarchique, et de Xpath.
  • # Poutre paille....

    Posté par . Évalué à 9.

    C'est vrai que c'était mieux avant !
    - Devoir configurer son éditeur de texte en lisp
    - Ou en python par ce que maintenant c'est la mode
    - Son MTA à coup de macro m4
    - Le logiciel que tu veux avec une syntaxe merdique qui fait saigner tes yeux
    - Ajoute ton exemple ici, y'en a plein
    - Tiens on pourrait parler d'apache aussi !

    Alors oui il y a de plus en plus de dev qui vont à la facilité, et dans certain cas on pourrait utiliser quelque chose de plus léger . Mais j'ai plus l'impression que certains font une réaction allergique par principe ou simplement par ce qu'ils ne veulent pas prendre 10 minutes pour se former. C'est peut être un peu plus verbeux, mais en utilisant les outils adéquats il a aussi des avantages, tant pour le développeur que pour l'utilisateur:
    - Savoir si son fichier de conf est valide en direct à l'édition
    - Auto documentation
    - Complétion automatique
    - Réutilisation des connaissances et des outils. Pas besoin d'apprendre 12 syntaxes différentes
    - En utilisant un outil adéquat, c'est pas tes petits doigts boudinés qui tapent le côté verbeux

    Y'a du pour et du contre...
    • [^] # Re: Poutre paille....

      Posté par . Évalué à 6.

      On peut parler de Xorg aussi !!!

      Section "MaSection"
      Option "typeDOption" "valeur"
      EndSection

      C'est sur que c'est mieux que :

      <MaSection typeDOption="valeur" />


      ça ressemble etrangement à :
      <MaSection>
      <typeDOption>valeur</typeDOption>
      </MaSection>


      \o/
      • [^] # Re: Poutre paille....

        Posté par . Évalué à 4.

        [masection]
        typeDOption="valeur"
        • [^] # Re: Poutre paille....

          Posté par . Évalué à 4.

          Et pour les subsections de Xorg (oui, cherche dans le man) ? Ok, ça peut se faire "[section/subsection]". Xorg utilise juste un format de conf qui est plutôt étrange aujourd'hui (vu qu'un format plus ordinaire (aujourd'hui) conviendrait aussi bien).
    • [^] # Re: Poutre paille....

      Posté par . Évalué à 4.


      Alors oui il y a de plus en plus de dev qui vont à la facilité, et dans certain cas on pourrait utiliser quelque chose de plus léger . Mais j'ai plus l'impression que certains font une réaction allergique par principe ou simplement par ce qu'ils ne veulent pas prendre 10 minutes pour se former. C'est peut être un peu plus verbeux, mais en utilisant les outils adéquats il a aussi des avantages, tant pour le développeur que pour l'utilisateur:

      MA réaction n'est ni une réaction de principe ni une réaction allergique.

      A la limite, dans le cas qui m'intéresse (cluster RedHat), si je disposais d'un utilitaire en ligne de commande permettant de générer correctement le fichier de conf, ça ne me gênerait pas plus que ça. Je suis sur d'ailleurs d'utiliser à mon insu des outils qui stockent leur config dans des fichiers XML, et ça ne me gène pas. Au pire si ça m'amuse je vais toucher le fichier XML. La ce que je déplore pour Redhat Cluster (et il ne doit pas être le seul), c'est d'utiliser un fichier XML et de ne pas avoir d'autre alternative que l'édition direct XML, soit une interface graphique.
      Et pour ton info, je me suis renseigné sur le XML, je connais assez bien celui-ci. Dans pas mal de cas c'est bien pratique. Mais dans le cas de fichier de conf pour une appli ça ne sert à rien. Il y a bien plus simple et plus pratique que ça.
      • [^] # Re: Poutre paille....

        Posté par . Évalué à 3.

        Mais dans le cas de fichier de conf pour une appli ça ne sert à rien.Tu proposerais quoi ?
        Il y a bien plus simple et plus pratique que ça.

        A ce que tu répondras, je dirais que XML est mieux. :)
        Je plaisante bien sur, mais tu critique XML sans me dire ce qui serait mieux et aussi supporté partout (même javascript gère le XML superbement)!

        ps : utilise vim pour édité du xml en console.
        • [^] # Re: Poutre paille....

          Posté par . Évalué à 2.

          un exemple :
          http://docs.kde.org/stable/fr/kdebase-runtime/userguide/conf(...)

          L'exemple à la fin me fait d'ailleurs bien rire :

          Je cite :

          Voici un exemple de fichier de configuration XML.

          <?xml version="1.0" encoding="UTF-8"?>
          <!DOCTYPE kcfg SYSTEM "http://www.kde.org/standards/kcfg/1.0/kcfg.dtd">




          Enable automatic saving of calendar
          true


          10




          Il a le même effet que :

          [General]
          Auto Save=false
          Auto Save Interval=25


          Les fichiers ini à la Windows n'étaient pas mal fichus pour ce qui me reste en mémoire.
          • [^] # Re: Poutre paille....

            Posté par . Évalué à 3.

            GRRRR!!!!! Je recite l'exmple :
            Voici un exemple de fichier de configuration XML :


            <?xml version="1.0" encoding="UTF-8"?>
            <!DOCTYPE kcfg SYSTEM "http://www.kde.org/standards/kcfg/1.0/kcfg.dtd">
            <kcfg>
            <kcfgfile name="korganizerrc"/>
            <group name="General">
            <entry type="Bool" key="Auto Save">
            <label>Enable automatic saving of calendar</label>
            <default>true</default>
            </entry>
            <entry type="Int" key="Auto Save Interval">
            <default>10</default>
            </entry>
            </group>
            </kcfg>

            Il a le même effet que :

            [General]
            Auto Save=false
            Auto Save Interval=25
            • [^] # Re: Poutre paille....

              Posté par . Évalué à 3.

              Je ne vois aucune valeur affectée dans ton exemple XML (pas de 25 par exemple, le 10 est la valeur par défaut), et aucune documentation dans le INI.
              Ces 2 exemples ne sont pas comparables en l'état. Ton XML est à mon avis une sorte de XSD dédié à "kcfg", appliqué à "korganizer".
            • [^] # Re: Poutre paille....

              Posté par (page perso) . Évalué à 9.

              Je suis d'accord avec toi sur l'abus d'XML pour les fichiers de config.

              Par contre, pour l'exemple que tu donnes, tu oublies d'indiquer que ce format XML n'est pas un fichier de config en tant que tel, mais un fichier de données de description de config destiné au programme GUI d'édition de la config:
              "des fichiers qui fournissent une description formelle des éléments possibles dans un fichier de configuration. Le nouvel éditeur de configuration KDE s'en sert quand ils sont disponibles."

              Bref, si j'ai bien compris, cet XML là est uniquement écrit une bonne fois pour toutes par le développeur pour le programme qui utilisera le fichier de config final (sans XML lui) pour que les outils graphiques puissent manipuler ledit fichier de config.

              Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

        • [^] # Re: Poutre paille....

          Posté par (page perso) . Évalué à 0.

          ps : utilise vim pour édité du xml en console.

          A propos de vim, voici un fichier sympathique à éditer avec vim:

          http://hules.free.fr/vim_SUXOR.xml
          • [^] # Re: Poutre paille....

            Posté par (page perso) . Évalué à 0.

            En effet, j'ai essayé avec notepad.exe et un redimensionnement de la fenêtre fige le logiciel pendant 20 secondes.

            Je ne vois qu'une solution. pan ! pan !
            • [^] # Re: Poutre paille....

              Posté par (page perso) . Évalué à 2.

              Par contre kate l'ouvre très bien (et a un mode vi).

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # libconfig

    Posté par (page perso) . Évalué à 7.

    Complètement d'accord, le XML ne se justifie pas du tout pour ça.

    Heureusement il y a libconfig :
    http://www.hyperrealm.com/libconfig/

    Qui permet de manipuler des fichiers de conf de ce type :
    http://www.hyperrealm.com/libconfig/test.cfg.txt
  • # deport

    Posté par . Évalué à 6.

    Tu parles d'utilisation de machines depuis l'extérieur (de la salle de ces machines). Et de la difficulté apporté par une configuration figée au travers d'une GUI, dans ce contexte.

    Je ne peux que plussoyer l'évidence de la bétise (oula) de forcer l'utlisation d'une GUI (d'ailleurs ça m'étonne ce truc, chez Redhat, je n'utilise pas cette cluster suite) d'une manière totalement générale. Que les fichiers de conf soient dans tel ou tel format, peu m'importe : le simple fait qu'ils ne puissent être générés que par une GUI m'horripile.

    ########

    Ben d'ailleurs, Redhat propose la suite d'outils "conga" pour cela : gérer son cluster depuis la ligne de commande, sans avoir besoin de gui.

    Par contre, sur le cas GUI Cluster Suite de Redhat : je suis très étonné d'une chose : que l'interface ne soit pas déportable. Vraiment très étonné. -> Es tu sûr que tu ne puisses pas utiliser la cluster Suite depuis ton laptop Redhat, en ciblant ton cluster distant ? Ainsi tu ne déportes pas l'affichage de la GUI, mais la GUI elle même : et la consommation réseau (ports, bp) se résume à la synchronisation de tes fichiers de conf.

    "provides the capability to create, edit, and propagate the cluster configuration file" ... donc vraiment je reste étonné et un peu dubitatif.

    "does not display the Send to Cluster button if the cluster is new and has not been started yet, or if the node from which you are running the Cluster Configuration Tool is not a member of the cluster. If the Send to Cluster button is not displayed, you can still use the Cluster Configuration Tool; de plus en plus dubitatif ;) Perso je crois que je ferais un rsync sur clefs entre mon poste d'admin et la machine centrale du cluster. (Et ça me semble étrange que cela ne soit pas intégré de base...bah de toutes façons c'est possible)

    Cdlt.
    • [^] # Re: deport

      Posté par . Évalué à 2.

      Par contre, sur le cas GUI Cluster Suite de Redhat : je suis très étonné d'une chose : que l'interface ne soit pas déportable. Vraiment très étonné. -> Es tu sûr que tu ne puisses pas utiliser la cluster Suite depuis ton laptop Redhat, en ciblant ton cluster distant ? Ainsi tu ne déportes pas l'affichage de la GUI, mais la GUI elle même : et la consommation réseau (ports, bp) se résume à la synchronisation de tes fichiers de conf.


      La difficulté est que je n'ai pas de laptop RedHat à l'extérieur. J'ai réussi à trouer une autre machine en interne (pas sous redhat d'ailleurs), export display et ensuite me connecter via VNC sur cette machine, avec un débit réseau pourri. Si j'avais eu un laptop redhat, je n'aurais pas été ennuyé.

      Perso je crois que je ferais un rsync sur clefs entre mon poste d'admin et la machine centrale du cluster. (Et ça me semble étrange que cela ne soit pas intégré de base...bah de toutes façons c'est possible)

      Mon poste de travail est sous Windows. :(. Pour la plupart des environnements que j'ai à gérer, je dispose d'un environnement x (au pire des cas, je peux travailler avec exceed), mais là je suis sur un cas particulier : ce n'est pas possible de façon simple.

      Sinon, Conga c'est une interface web ... A moins que quelque chose m'ait échappé, toujours est-il que je n'ai pas
      • [^] # Re: deport

        Posté par . Évalué à 1.

        Je crois que, enfin peu importe :p (exceed est une bouse innomable).

        La doc de Redhat explicite bien que l'ensemble est disponible en ligne de commande. http://www.redhat.com/docs/manuals/csgfs/browse/4.6/Cluster_(...)

        De toutes façon le déport d'affichage n'est pas une solution, et la ligne de commande risque d'être périeuse (...) Installe une Redhat sur ton laptop, travaille avec la gui locale, et exporte le tout sur le cluster. (ça permet aussi j'imagine de valider avant export, sur un 'faux' cluster de vm servant de maquette de travail, par exemple)

        Mais vraiment, faut pas pousser mémé dans les orteils, tu es sans doute confronté au syndrome "du blaireau qui ordonne à une ssii"... Alors, pas de blème : fonce sur Conga, ils sont tellement cons que le port 80 c'est à la mode, et ils autoriseront sans doute plus facilement conga qu'une obscure connection ssh (parcequ'ils n'ont pas de hierarchie ni d'officier de sécu à qui confier les clefs, au hasard...). Le web, le cloud et les cluster sont à la mode, plus c'est gros plus ça passe : tape dans le 80. :)
        • [^] # Re: deport

          Posté par . Évalué à 1.

          La doc de Redhat explicite bien que l'ensemble est disponible en ligne de commande. http://www.redhat.com/docs/manuals/csgfs/browse/4.6/Cluster_(...)

          Sauf si j'ai raté quelque chose, il n'est pas possible via ces comandes de définir une ressource ou de créer un failover domain par exemple. Je veux bien croire que j'ai raté quelque chose (une subtilité quelque part qui m'a échappé), mais bon ... Je regarde à nouvea et je ferai un retour.

          De toutes façon le déport d'affichage n'est pas une solution, et la ligne de commande risque d'être périeuse (...) Installe une Redhat sur ton laptop, travaille avec la gui locale, et exporte le tout sur le cluster. (ça permet aussi j'imagine de valider avant export, sur un 'faux' cluster de vm servant de maquette de travail, par exemple)
          je n'ai pas la possibilité d'installer un cluster sur un autre poste pour le moment. D'autre part j'ai déjà trouvé une solution de contournement (mais provisoire). Mon journal était là pour raler, et pour essayer de comprendre l'intéret d'utiliser des fichiers xml pour la conf d'un cluster, et par extension l'intéretde fichers xml pour les confs en général (le second exemple qui me vient à l'esprit est le système d'arrêt/relance des services de solaris 10).

          Mais vraiment, faut pas pousser mémé dans les orteils, tu es sans doute confronté au syndrome "du blaireau qui ordonne à une ssii"... Alors, pas de blème : fonce sur Conga, ils sont tellement cons que le port 80 c'est à la mode, et ils autoriseront sans doute plus facilement conga qu'une obscure connection ssh (parcequ'ils n'ont pas de hierarchie ni d'officier de sécu à qui confier les clefs, au hasard...). Le web, le cloud et les cluster sont à la mode, plus c'est gros plus ça passe : tape dans le 80. :)

          Le port 80 est déjà censé être utilisé sur cette machine :(. Le port 443 aussi. Sion ce serait trop simple. Non dans ce cas ce n'est pas une politiiqe blaireau.
          • [^] # Re: deport

            Posté par . Évalué à 2.

            Non non tu dois mieux connaitre le sujet que moi puisque tu y es confronté, alors que je n'ai fait que survolé la doc. (malheureusement :p )

            Redhat fourni des outils en ligne de commande, peut être pas assez complet ? Une interface web, semble pas mal ? Et une interface graphique native locale, pas mal aussi ? Cela fait quant même un bel ensemble et je ne vois pas trop ce qu'ils pourraient faire de mieux ? peut être améliorer les cli ?

            D'où ma grossièreté de "politique de blaireau" du genre on oblige les utilisateurs à avoir un poste windows alors que le besoin métier demande un poste linux. Sinon, l'utilisateur va passer beaucoup de temps en bidouille, en rebond, pour au final être moins productif.
            • [^] # Re: deport

              Posté par . Évalué à 2.

              D'où ma grossièreté de "politique de blaireau" du genre on oblige les utilisateurs à avoir un poste windows alors que le besoin métier demande un poste linux. Sinon, l'utilisateur va passer beaucoup de temps en bidouille, en rebond, pour au final être moins productif.
              La malhereusement c'est le cas ... :)
  • # Il semble que chez la concurrence ...

    Posté par . Évalué à 1.

    ... le shell objet permet de manipuler le XML comme on liste un répertoire.

    est-ce la solution ? (un shell orienté objet)

    Si c'est le cas, il faut bien commencé par s'occuper des fichiers de conf avant le shell.

    Le KSH permet-il de faire cela ?
    (parser, et modifier naturellement des fichiers XML)

    Merci !
  • # Evolution

    Posté par . Évalué à 4.

    A long terme, pour le stoquage des settings tout en restant compatible d'une version à une autre, le XML est 'achement pratique.
    Suffit de mettre dans une balise parent le num de version (1.0.0) par exemple, et quand le soft évolue, les settings changent. Quand je place une config de la version 1.0.0 dans une install 2.0.0, il sait la lire (s'il a garder la fonction, biensur) tout en écrivant la nouvelle version de ses settings.

    Evidement, tout est faisable avec un simple .ini, l'intéret c'est que le XML est plus standard, et les parseurs sont légions.
  • # script

    Posté par . Évalué à 1.

    Et le mieux c'est les projets qui font des scripts avec XML comme fontconfig [1].
    M'enfin l'étape au dessus c'est des trucs à la gconf, où c'est tellement complexe qu'on ne peut pas l'éditer à la main.


    [1]

    <code>
    <?xml version="1.0"?>
    <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
    <fontconfig>
    <!--
    If the font still has no generic name, add sans-serif
    -->
    <match target="pattern">
    <test qual="all" name="family" compare="not_eq">
    <string>sans-serif</string>
    </test>
    <test qual="all" name="family" compare="not_eq">
    <string>serif</string>
    </test>
    <test qual="all" name="family" compare="not_eq">
    <string>monospace</string>
    </test>
    <edit name="family" mode="append_last">
    <string>sans-serif</string>
    </edit>
    </match>
    </fontconfig>
    </code>
    • [^] # Re: script

      Posté par . Évalué à 2.

      Je ne suis pas développeur gnome mais ne dirais tu pas un peu n'importe quoi à propos de GConf ? Les fichiers de configurations sont trivialement simples et il est très facile de comprendre comment cela marche et de les éditer à la main.

      Je ne savais pas comment ca marchait il y a dix minutes. Mais en utilisant son cerveau, ce n'est pas très difficile à faire soit même.

      1- Ouvrir le schema de l'application. Ici ça sera /etc/gconf/schemas/desktop_gnome_background.schemas
      2- Identifier la clé à configurer dans ce fichier. On trouve facilement, le nom de la clé, le type de valeur, la valeur par défaut et la documentation.
      3- Ouvrir le fichier de configuration: ~/.gconf/desktop/gnome/background/%gconf.xml
      4- Ajouter ou modifier la clé:
      <entry name="picture_filename" mtime="1262709633" type="string">
      <stringvalue>/tmp/1.jpg</stringvalue>
      </entry>

      C'est clair que c'est atrocement compliqué et totalement hors de portée... Tu peux nous proposer une solution fonctionnellement équivalente et beaucoup plus simple ? Si tu trouves tu pourras proposer un patch pour ajouter un nouveau backend !


      Ce que tu critiques c'est une limitation actuelle de gconf qui n'a strictement rien avoir avec les fichiers de configuration. Gconf est un serveur de configuration qui offre une API pour configurer et consulter les valeurs et de les stocker de manière pérenne en utilisant un backend. Par défaut le backend XML est utilisé. Le démon tourne en permanence, il doit être utiliser pour consulter la valeur d'une clé et peut être utilisé pour la configurer. Il s'occupe aussi de notifier les applications quand une clé change. Comme ils font bien les choses chez gnome, voir http://library.gnome.org/devel/gconf/stable/gconf-gconf-backend.html , il est prévu qu'un backend puisse notifier qu'une valeur a été changé sans passer par l'API ( ce qui correspond dans notre cas à une édition manuelle du fichier XML). Actuellement le backend XML n'implémente pas cette fonctionnalité, cf NULL, /* set_notify_func */ ligne 231 dans xml-backend.c

      On peut très facilement imaginer pourquoi c'est difficile à implémenter: gestion des conflits, réconciliation, état incohérents etc. Si le sujet t'intéresse, tu peux proposer un patch je pense.

      Alors tu peux très bien faire la manip à la main, mais actuellement il faut que tu arrêtes ton démon gconf, que tu édites le fichier et que tu redémarre le démon.

      Si un dev gnome veut me corriger il est le bienvenu ! Certains ont la critique et le préjugé facile je trouve...
      • [^] # Re: script

        Posté par . Évalué à 1.

        1- Ouvrir le schema de l'application. Ici ça sera /etc/gconf/schemas/desktop_gnome_background.schemas
        Ce fichier n'existe pas chez moi, pourtant j'ai des applis qui utilisent gconf

        C'est clair que c'est atrocement compliqué et totalement hors de portée
        La preuve je suis bloqué au 1.

        On peut très facilement imaginer pourquoi c'est difficile à implémenter: gestion des conflits, réconciliation, état incohérents etc. Si le sujet t'intéresse, tu peux proposer un patch je pense.
        Si on veut faire un truc aussi complexe autant utilisé une base de donné de type sqlite

        Tu peux nous proposer une solution fonctionnellement équivalente et beaucoup plus simple
        Un truc plus simple :
        - des fichiers de conf classique clef valeur (comme sshd_config) par exemple.
        Ce fichier contient des commentaires et les valeurs par défaut : la doc est dans le fichier de config [tout du moins pour les fichiers globaux, pour les fichiers user c'est discutable de dupliquer la doc]
        - un démon optionnel peut vérifier si les fichiers sont modifiés (via ionotify) et signalé au appli correspondante quel doive relire le fichier de config. La notification peut se faire par signaux (les fameux SIGHUP), ou alors un mécanisme plus complexe.
        - si tu veux vraiment gérer les confits, tu peux mettre ces fichier sur un gestionnaire de revision : le fichier est pris en compte une fois que tu l'a commité. En bonus tu gagne un historique qui peut te permettre de récupérer une version qui marchait.

        PS : Question pour la route comment tu modifies les paramètres gconf de gdm ?
        PS2 : Comment tu lances un appli qui dépend de gconf dans une sandbox (limité à un process, isolé du reste du système).
      • [^] # Re: script

        Posté par . Évalué à 2.

        Je reste quand même d'avis que la conf d'un GUI est suffisamment complexe pour ne pas avoir besoin d'être modifiée hors interface GUI, et qu'un outil graphique est mieux adapté, donc un fichier de conf XML à ce niveau ne me gêne pas.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.