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.
Journal Requête aux devs de logiciels libres
4
jan.
2010
# Vous devez entrer un sujet et un commentaire
Posté par Troy McClure (site web personnel) . Évalué à 10.
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 totof2000 . Évalué à 10.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par kowalsky . Évalué à 3.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par totof2000 . Évalué à 3.
La encore c'est le développeur qui est favorisé et non l'utilisateur.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
D'après un trolleur fou de fcol.debats, on peut dire pipe de prod :)
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Vivien MOREAU . Évalué à 1.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Croconux . Évalué à 4.
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 totof2000 . Évalué à 3.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par swilmet . Évalué à 6.
Je pense que dans la plupart des cas c'est amplement suffisant, et donc pas besoin de réécrire un parseur.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Thomas Douillard . Évalué à 6.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par totof2000 . Évalué à 2.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Littleboy . Évalué à 4.
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 Brioche4012 (site web personnel) . Évalué à 4.
http://en.wikipedia.org/wiki/Yaml
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par totof2000 . Évalué à 4.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
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 Croconux . Évalué à 4.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Octabrain . Évalué à 7.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par BAud (site web personnel) . Évalué à 1.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Vivien MOREAU . Évalué à 3.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Miod in the middle . Évalué à 2.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par stopspam . Évalué à 2.
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 Octabrain . Évalué à 2.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par totof2000 . Évalué à 1.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par ckyl . Évalué à 4.
Tu peux reprendre l'exemple du META.yml utilisé ici: https://linuxfr.org//comments/1054702.html#1054702
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par ckyl . Évalué à 10.
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 Croconux . Évalué à 6.
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 vg . Évalué à 1.
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 Octabrain . Évalué à 6.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par vg . Évalué à 2.
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 lolop (site web personnel) . Évalué à 2.
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 dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Antoine Reilles (site web personnel) . Évalué à 5.
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 lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par totof2000 . Évalué à 2.
[^] # Re: Vous devez entrer un sujet et un commentaire
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
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 Pol' uX (site web personnel) . Évalué à 2.
http://www.nongnu.org/confuse/
Adhérer à l'April, ça vous tente ?
# XML et GUI ?
Posté par kowalsky . Évalué à 7.
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 totof2000 . Évalué à 2.
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 kowalsky . Évalué à 3.
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 BAud (site web personnel) . Évalué à 5.
cf. Business_loto
[^] # Re: XML et GUI ?
Posté par totof2000 . Évalué à 1.
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 totof2000 . Évalué à 3.
[^] # Re: XML et GUI ?
Posté par kowalsky . Évalué à 2.
[^] # Re: XML et GUI ?
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: XML et GUI ?
Posté par totof2000 . Évalué à 2.
[^] # Re: XML et GUI ?
Posté par kowalsky . Évalué à 2.
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 totof2000 . Évalué à 3.
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 jeffcom . Évalué à 4.
[^] # Re: XML et GUI ?
Posté par totof2000 . Évalué à 2.
[^] # Re: XML et GUI ?
Posté par jeffcom . Évalué à 5.
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 totof2000 . Évalué à 2.
<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 totof2000 . Évalué à 2.
<rm>
<failoverdomains/>
<resources>
<ip address="aaa.bbb.ccc.ddd" monitor_link="1"/>
</resources>
</rm>
[^] # Re: XML et GUI ?
Posté par thedude . Évalué à 2.
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 Croconux . Évalué à 4.
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 totof2000 . Évalué à 2.
- 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 claudex . Évalué à 3.
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 totof2000 . Évalué à 2.
[^] # Re: XML et GUI ?
Posté par jeffcom . Évalué à 2.
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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: XML et GUI ?
Posté par totof2000 . Évalué à 3.
-ipf/pf :
* par ligne
* très lisible et très facilement éditable
[^] # Re: XML et GUI ?
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: XML et GUI ?
Posté par Zakath (site web personnel) . Évalué à 6.
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 kowalsky . É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 psychoslave__ (site web personnel) . Évalué à 1.
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 Thomas Douillard . Évalué à 3.
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 ...
[^] # Re: Outils en CLI
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Outils en CLI
Posté par totof2000 . Évalué à 2.
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/(...)
Je suis en RHEL5.
[^] # Re: Outils en CLI
Posté par inico (site web personnel) . Évalué à 2.
Tu as testé pour voir si la doc est dépassé ?
[^] # Re: Outils en CLI
Posté par totof2000 . Évalué à 3.
[^] # Re: Outils en CLI
Posté par inico (site web personnel) . Évalué à 5.
Pas très loin du lien précédant.
As-tu réellement cherché ?
[^] # Re: Outils en CLI
Posté par totof2000 . Évalué à 2.
la commande en question lance l'interface graphique.
As-tu vraiment lu le lien que tu as posté ?
Sinon il y a peut-être une section quelque part qui me permet d'ajouter les ressources et les services en ligne de commande, mais je ne l'ai pas vu (et il me semble avoir fait toutes les pages de la doc que tu as fournie en lien).
[^] # Re: Outils en CLI
Posté par inico (site web personnel) . Évalué à 3.
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.(...)
Sinon, tu peut toujours jouer avec Conga qui est une interface web:
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.(...)
[^] # Re: Outils en CLI
Posté par totof2000 . Évalué à 2.
# GLMF est d'accord avec toi
Posté par psychoslave__ (site web personnel) . Évalué à 3.
http://www.gnulinuxmag.com/index.php/2009/10/30/edito-gnulin(...)
[^] # Re: GLMF est d'accord avec toi
Posté par totof2000 . Évalué à 2.
[^] # Re: GLMF est d'accord avec toi
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 1.
# Règle du KISS et XML
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
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 totof2000 . Évalué à 2.
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 Littleboy . Évalué à 7.
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 totof2000 . Évalué à 5.
[^] # Re: Règle du KISS et XML
Posté par Gniarf . Évalué à 2.
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 totof2000 . Évalué à 2.
[^] # Re: Règle du KISS et XML
Posté par Gniarf . Évalué à 3.
[^] # Re: Règle du KISS et XML
Posté par psychoslave__ (site web personnel) . Évalué à 2.
* ~/.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 totof2000 . Évalué à 5.
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 Laurent J (site web personnel, Mastodon) . Évalué à 1.
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 Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
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 totof2000 . Évalué à 2.
[^] # Re: Règle du KISS et XML
Posté par totof2000 . É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 inconvénients "
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Règle du KISS et XML
Posté par thedude . Évalué à 0.
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 Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Règle du KISS et XML
Posté par thedude . Évalué à 0.
<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 Mareo . Évalué à 1.
[^] # Re: Règle du KISS et XML
Posté par thedude . Évalué à 1.
Alors, peut tu nous explique nous comment tu ferais un truc qui soit pas immonde?
[^] # Re: Règle du KISS et XML
Posté par Mareo . Évalué à 1.
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 thedude . Évalué à 0.
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 Mareo . Évalué à 1.
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 thedude . Évalué à 6.
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 psychoslave__ (site web personnel) . Évalué à 1.
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 claudex . Évalué à 2.
« 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 psychoslave__ (site web personnel) . Évalué à 2.
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 claudex . Évalué à 2.
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 psychoslave__ (site web personnel) . Évalué à 1.
[^] # Re: Règle du KISS et XML
Posté par psychoslave__ (site web personnel) . Évalué à 1.
%!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 totof2000 . Évalué à 3.
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 Littleboy . Évalué à 7.
- 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 Moonz . Évalué à 2.
Hard cases make bad laws.
[^] # Re: Règle du KISS et XML
Posté par totof2000 . É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 Littleboy . Évalué à 1.
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 totof2000 . Évalué à 2.
[^] # Re: Règle du KISS et XML
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
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 Olivier Jeannet . Évalué à -1.
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 totof2000 . Évalué à 2.
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 thedude . Évalué à 1.
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 psychoslave__ (site web personnel) . Évalué à 4.
[^] # Re: Règle du KISS et XML
Posté par Olivier Jeannet . Évalué à 1.
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 totof2000 . Évalué à 1.
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 Thomas Douillard . Évalué à 3.
[^] # Re: Règle du KISS et XML
Posté par wismerhill . Évalué à 1.
http://xmlstar.sourceforge.net/
(je m'en sers beaucoup pour pouvoir scripter la lecture/édition de fichiers de config de tomcat)
# Poutre paille....
Posté par ckyl . Évalué à 9.
- 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 kowalsky . Évalué à 6.
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 totof2000 . Évalué à 4.
typeDOption="valeur"
[^] # Re: Poutre paille....
Posté par Octabrain . Évalué à 4.
[^] # Re: Poutre paille....
Posté par totof2000 . É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 kowalsky . É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 totof2000 . Évalué à 2.
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 totof2000 . Évalué à 3.
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 Octabrain . Évalué à 3.
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 totof2000 . Évalué à 1.
[^] # Re: Poutre paille....
Posté par Octabrain . Évalué à 0.
[^] # Re: Poutre paille....
Posté par lolop (site web personnel) . Évalué à 9.
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 dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Poutre paille....
Posté par Troy McClure (site web personnel) . Évalué à 0.
A propos de vim, voici un fichier sympathique à éditer avec vim:
http://hules.free.fr/vim_SUXOR.xml
[^] # Re: Poutre paille....
Posté par grid . Évalué à 0.
Je ne vois qu'une solution. pan ! pan !
[^] # Re: Poutre paille....
Posté par claudex . Évalué à 2.
« 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 hsyl20 (site web personnel) . Évalué à 7.
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 bubar🦥 (site web personnel) . Évalué à 6.
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 totof2000 . Évalué à 2.
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 bubar🦥 (site web personnel) . É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_(...)
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 totof2000 . Évalué à 1.
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 bubar🦥 (site web personnel) . Évalué à 2.
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 totof2000 . Évalué à 2.
La malhereusement c'est le cas ... :)
# Il semble que chez la concurrence ...
Posté par Flavien . Évalué à 1.
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 !
[^] # Re: Il semble que chez la concurrence ...
Posté par bubar🦥 (site web personnel) . Évalué à 2.
( http://thepowershellguy.com/blogs/posh/archive/2007/12/30/pr(...) )
okok je connais la route...
[^] # Re: Il semble que chez la concurrence ...
Posté par bubar🦥 (site web personnel) . Évalué à 1.
non ?
[^] # Re: Il semble que chez la concurrence ...
Posté par Gniarf . Évalué à 7.
# Evolution
Posté par Stibb . Évalué à 4.
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.
[^] # Re: Evolution
Posté par psychoslave__ (site web personnel) . Évalué à 2.
#!software=foo
#!version=1.0.0
foo=bar
bar=foo
# script
Posté par M . Évalué à 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 ckyl . Évalué à 2.
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 M . Évalué à 1.
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 totof2000 . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.