Les clients OSM sont codés en fonction de ce que OSM envoie, non ? Je veux dire que si OSM passe au vectoriel, alors les clients vont (bien obligés) suivre.
Non
OSM c'est avant tout de la donnée. De la donnée brut. Il faut alors la rendre (générer la carte). Et là plusieurs serveurs existent.
Ensuite, côté client, ben en général c'est souvent du WMS / WFS / TMS / KML. En dehors de ça y'a pas énormément de choses.
Et les clients sont souvent des clients TMS (tuiles) car c'est quand même simple.
Les clients ne sont pas spécifiques à OSM, loin de là. En général ce sont des clients qui lisent les formats OGC (plus ou moins).
J'avoue être surpris par ces problèmes de "rendu de carte" alors que la moindre config vendue actuellement est capable de faire tourner un jeu 3D du genre d'OpenArena. À priori ça me paraît capable de faire le rendu d'une carte à partir de données de base :|
Le problème n'est pas uniquement en temps de rendu. Déjà il y a quand même un côté idiot à vouloir que tout le monde rende la même donnée, ça va un peu à l'encontre d'une mutualisation de moyen et fait du boulot auprès de tout le monde.
Ensuite, je pense que tu sous-estime le temps de dessin d'une (ou plusieurs) tuiles. Si les gens apprécient Google Maps (comme dit dans l'article) c'est parce que ça va vite. Il est illusoire de croire qu'on peut avoir les mêmes performances sans un minimum de prégénération de tuiles.
Bon après c'est pas si blanc/noir, lorsqu'on envoi un kml à afficher à Google il l'envoi sur ces serveurs et le tuile côté serveur plutôt que de le rendre côté client. Idem pour les markers.
Mais concrètement, côté temps de rendu on aura pas de bonnes performances. Et un moteur de rendu c'est pas si léger que ça non plus.
Une tuile vectorielle c'est déjà différent car c'est juste que ce n'est pas une image bitmap qui est envoyée mais une image vectorielle. Une partie du traitement est déjà faite.
Pour présenter un peu les autre problématiques au rendu côté client : le placement des étiquettes de lieux, nom de rue, etc. C'est une opération qui est loin d'être négligeable. Lesquelles afficher. Gestion de conflits. Gestion d'importance. Comment faire pour que leur position ne dépende pas de la vue du client. etc.
Je ne crois pas.
Dans tous les cas le problème de tuiles vectorielles est que ça ne fait plus vraiment un TMS et qu'il faut rendre (dessiner) ces tuiles côté client. Vu que les tuiles vectorielles ne sont pas vraiment standards et que les nombreux clients ne les supportent pas, ça devient malheureusement peu envisageable.
Maintenant rien n'empêcherait d'en générer (ce qui serait il est vrai intéressant côté place et donc bande passante nécessaire, le tout contre un coût d'affichage un peu plus élevé - en terme de puissance demandée)
Bon, je comprends plus. Tu as assez de bande passante ou pas ?
Sachant que l'espace de stockage n'est pas un problème, j'ai de quoi stocker tout le contenu de OSM.
Heu, quelle partie du contenu ? Les données (je crois dans les 250Go) mais qu'en est-il des tuiles ? Si tu veux tout rendre il faut compter dans les 54To, la partie communément visible faisant de l'ordre de 1.2To (http://wiki.openstreetmap.org/wiki/Tile_Disk_Usage)
Héberger une partie de la data tout seul dans ton coin ça va pas servir à grand chose, ce qui compte c'est aussi de pouvoir rendre la tuile (et ça on va pas le faire sur chaque client, d'ailleurs ce serait plutôt idiot car ça voudrait dire que chaque client embarque un serveur de rendu carto) et les perfs seraient assurément catastrophiques.
Mais dans tous les cas, je vois pas bien le rapport avec http dans l'histoire.
Qu'est ce qui est bloquant avec HTTP dans ton histoire et qui ne le serait pas avec un autre protocole ? En quoi un autre protocole résoudrait le problème ?
Parce que je n'ai pas assez de bande passante pour ne serait-ce que 10 personnes qui regardent une carte en même temps depuis chez moi. Et c'est tout le problème avec HTTP
Heu, http ou pas si tu n'as pas assez de bande passante … ben t'en as pas assez.
tu te retrouves avec un serveur qui va servir un nombre indéterminé de clients
Quel est le rapport avec HTTP ? Tu peux très bien avoir un service http qui te répond une 503 service unavailable lorsque le nombre d'utilisateur maximum autorisé est atteint.
Le client est connecté à un seul serveur, et l'utilisateur s'impatiente si ça rame.
Pas forcément. Le but des CDN est justement contraire non ? En gros le DNS va prendre en compte certains critères pour te diriger vers le bon serveur (entre autre, en général, la localisation géographique afin de te faire servir par un serveur le plus proche possible, mais rien n'empêche d'avoir d'autres critères comme la disponibilité, le temps de réponse, le statut, etc).
C'est une obsession, le "navigateur" ?
Non, c'est juste un exemple. Et la réponse "comment je fais ailleurs" n'y répond justement pas.
Comment je fais pour regarder OSM dans mon client IRC, moi ? :|
Et le truc c'est que HTTP est tout fait pertinent lorsqu'il s'agit de fournir une ressource. Ecrire un client HTTP est simple et si tu veux avoir ta localisation dans ton client IRC ça devient justement simple puisqu'il te suffit d'une url pour que ça fonctionne. Et sur ton super client, comme t'aimes bien la séparation, tu peux simplement lui demander de faire un curl de la bonne url dans un fichier temporaire, ton client irc va alors afficher le fichier image dans et hop, c'est fait. Il est donc où le problème avec HTTP ?
En fait, je viens de me rendre compte que t'es super fort, comment tu fais, tu as un grep qui tourne en permanence sur les commentaires / journaux pour chopper tout ce qui tourne autour d'http ?
Ce serait génial de s'appuyer sur le succès de OSM pour le rendre plus performant à chaque nouvel utilisateur, au lieu de crever des serveurs sous la charge
Ha ok, comme ça c'est chaque utilisateur que tu va blinder…
On ne peut pas utiliser les outils du Minitel 2.0 (la webbisation à outrance, avec un NDD qui regroupe toutes les données et les distribue) pour un projet collaboratif
On doit pas avoir la même définition du minitel 2.0 alors.
la "webbisation" n'a pas vraiment de lien avec le minitel, c'est beaucoup plus la centralisation et le fournisseur unique.
OSM n'est pas dans ce cas puisque tu peux très bien récupérer les données et les faire fournir par ton propre service. Donc où est le côté minitel 2.0 ?
J'aimerais bien contribuer à OSM en proposant un "cache" des données, et je pense pas être le seul :)
Heu, ben pourquoi tu ne le fais pas ?
Celui qui attend d'OpenStreetMap la même qualité de service que celle de Google Maps, avec un bon CDN, avec de la capacité à monter en charge et des infrastructures redondantes, comme dans l'offre Google
D'un autre côté, le protocole HTTP est pas super bien foutu pour distribuer les mêmes données identiques à plein de gens.
Oué enfin y'a pas que http. Pour monter en charge, pour avoir des infra redondantes, que tu utilises http ou pas le problème reste sensiblement le même.
Et d'ailleurs tu peux aussi avoir un CDN en P2P, c'est pas du tout incompatible.
Donc où est le problème ?
Maintenant, sans http, comment tu fais pour afficher un plan de localisation sur une page web ? Ok, tu vas me dire que ça devrait pas être dans le web, mais c'est faux. Donc comment tu fais ? Tu fais un nouveau protocole et tu l'implémente dans ton navigateur ?
multiplier les formats n'est pas forcément un avantage. Il vaut mieux, selon les contraintes, utiliser quelque chose de mal adapté mais assez bien maîtrisé qu'un format spécifique.
Ca dépend vraiment des cas.
Un projet qui aurait par exemple sa conf en yaml, qui sérialiserait un certain nombre de données en json (stockées par exemple en base, renvoyées au client web, etc), voir même qui boufferait du json directement depuis postgresql, et qui aurait aussi de l'xml à certains endroit, juste pour pouvoir utiliser du xsl et faire des transformations intéressantes ne me choque pas plus que ça.
La critique était valable, il me semble, il y a quelque temps, lorsque les libs n'étaient pas là.
Mais si on a un parseur/lib correct pour les différents format alors il n'y a aucun soucis, d'ailleurs à ce moment le format devient quasiment transparent. Par exemple, dernièrement j'ai utilisé gson pour sérialiser différentes informations, ben y'a pas à chier c'était bien plus rapide que de le faire en xml.
D'ailleurs, json a un avantage certain sur xml : plus personne ne fait d'ajax, quasiment tout le monde fait de l'ajaj (oué on pourrait aussi juste dire aj), les données sont de plus en plus envoyées / reçues en json. L'XML était peut-être une bonne idée, mais lorsqu'on voit le coup d'un parse xml / xsl côté client, on oublie vite.
Et donc si on dialogue en json, on a tout intérêt à stocker / cacher / etc les données en json pour pouvoir dialoguer à moindre coût.
Tu connais pas très bien EELV ? c'est pas très dur de trouver leurs positions sur l'avortement …
Je pense que t'as pas vraiment compris mon message, c'était une figure de style si tu préfère. Je sais très bien qu'on peut trouver la position d'EELV sur tous ces sujets.
Mais le commentaire initial était du genre "le parti pirate il s'occupe rien que de l'internet donc il ne peut pas avoir de position sur le reste". La logique voudrait que ce soit la même chose pour les partis centrés sur un sujet précis. Ou pas justement. EELV montre qu'un parti qui réunit des personnes sur un sujet précis (façon de parlé) peut avoir aussi des positions sur le reste.
Ce n'est surement pas encore le cas du parti pirate mais rien ne l'empêche en réalité.
Tu semblais affirmer que xml, on en reparle tout les 10 ans et qu'entre temps il ne fait plus parler de lui.
Non, ce qu'il dit est que le moment de gloire d'XML c'était il y a 10 ans. Maintenant c'est has been dans la majorité des cas (j'exagère un peu, mais au moins il ne devrait pas y avoir d'ambiguïtés)
utilisé par l'administration (ils font toujours de mauvais choix, n'est ce pas ?)
Heu… aucun rapport entre administration et bon ou mauvais choix. D'ailleurs, peu de différence au final entre administration et "grand compte" ou ssii, c'est en général plutôt mauvais dans tous les cas :-(
SOAP
Le problème de SOAP c'est juste que c'est imbitable comme techno et que beaucoup tente à tout prix de l'éviter et s'en portent beaucoup mieux (à moins de vouloir jouer uniquement avec des générateurs de code dans tous les sens)
Personnellement j'apprécie en xml le fait d'avoir des noeuds typés ce que l'on a pas en json.
Oui pour ce point. Malheureusement vu le nombre de fois où on touche du XML sans avoir de schéma ou dtd, le typage ne sert pas à grand chose…
il peux être intéressant de se demander ce à qu'il se passe et de se remettre en question.
Oui, il faudrait.
XML a de bons avantages, mais il à l'inconvénient majeur d'être implanté. Il est devenu, de fait, un standard dans la sérialisation texte. Donc la majorité des gens utilisent, lorsqu'ils veulent du texte, du .ini ou dès que le .ini ne suffit pas, du xml. D'ailleurs sans forcément réfléchir.
Et, par méconnaissance essentiellement, les gens ne vont pas chercher plus loin, des parseurs existes, et hop xml.
Pour le côté méconnaissance : si je prend les développeurs que je connais, il n'y en a pas la moitié qui a déjà entendu parlé de YAML par exemple.
oulala, je crois que c'est l'heure de la camomille…
Relis ce que j'écris avant d'inutiler
Ca tombe bien j'ai même pas inutilé.
Je n'ai pas dire que les usages étaient bons
Justement, ce que j'en dis c'est que la majorité des usages d'xml sont mauvais.
Que le xml te plaise ou non il est très employais
Ha mais le xml me plait. Mais surtout pas n'importe où.
Donc ce n'est pas un effet de mode contrairement à ce qui était sous entendu
Je pense que si, par certains côtés, c'est un effet de mode.
Il y a un temps, tout le monde faisait du xml, pour tout et n'importe quoi. Là c'était vraiment la mode. D'ailleurs il n'y a qu'à voir un certain nombre de frameworks java qui utilisent beaucoup trop le xml pour s'en rendre compte.
Aujourd'hui on l'utilise beaucoup moins et c'est beaucoup mieux (enfin sauf dans pas mal de projets java qui n'évoluent malheureusement pas dans le bon sens). On arrive alors à un usage à peu près raisonné et intelligent de l'xml. Mais c'est pas encore le cas partout.
Quel va être le programme du "parti pirate" sur l'avortement ? Sur la guerre en Syrie ? Sur l'écologie ? Sur le chomâge ? Sur les retraites ? Sur l'euthanasie ? Sur l'Union Européenne ? Sur la fiscalité ?
Ha oui, un peu comme :
Quel va être le programme de "EELV" sur l'avortement ? Sur la guerre en Syrie ? Sur l'écologie ?(ok, ça c'est bon) Sur le chomâge ? Sur les retraites ? Sur l'euthanasie ? Sur l'Union Européenne ? Sur la fiscalité ?
Il était évident que l'utilisation du mot "hype" place ta phrase dans un contexte d'ironie
Ha bon ? Et pourquoi donc ?
ils utilisent probablement des iMac ou des ipads
Même pas vrai, j'ai un macbook. De toute façon on voit bien qu'en fait vous êtes juste jaloux de ne pas pouvoir vous offrir de produit Apple.
Salauds de pauvre !
java l'utilise encore autant, mais il s'est doté de techniques pour mieux le gérer avec les annotations
Oué enfin (l'écosystème) java l'utilise toujours pour tout et n'importe quoi. Par exemple entre une configuration de servlets dans un web.xml et un module servlet de guice mon choix est très vite fait (en plus du fait que c'est beaucoup plus puissant…)
en réseaux xmpp l'utilise massivement
ça tombe bien c'est souvent ce qui lui est reproché. Il ne faut pas confondre le fait qu'ils l'utilisent et la pertinence de son usage.
des outils comme maven et ant utilisent xml et son très populaires
Oué, sauf qu'on fait absolument pas du maven pour le côté xml. Si on pouvait d'ailleurs faire du maven sans la lourdeur intrinsèque à l'xml on s'en porterait beaucoup mieux.
Ce ne sont que quelques exemples
Oui mais le problème c'est que dans ces exemples il n'y en a aucun qui donne envie de faire du xml.
Pour odf/ooxml et rss/atome c'est bien les seuls cas que je trouve intéressant. Mais le reste…
Quitte à faire quelque chose de nouveau, autant que ça soit au top, non ?
Sur le principe oui.
En pratique, non, surtout pas.
Surtout pas, car c'est dans ce genre de quête qu'on se perd souvent, qu'on perd beaucoup de temps et au final on a rien. Surtout si on vise cette perfection initialement.
Il y a pas mal de maximes sur le sujet, la plus connue étant "le mieux est l'ennemi du bien".
On peut ensuite parler de worse is better.
Et dans les faits on se rend compte que, souvent, les solutions moins optimales mais plus souples fonctionnent mieux et sont plus adoptées car au final elles correspondent à beaucoup plus de cas, et pour les cas limites sont suffisamment malléables pour s'adapter.
Il n'y a qu'à voir aussi les xkcd (ok, toujous le même) qui est balancé ci et là sur les standards).
Oué je sais, j'ai tiqué sur un point de détail, mais malheureusement ce type de raisonnement "autant faire parfait tout de suite" est extrêmement contre-productif, c'est même un véritable fléau en entreprise et plus généralement quelque soit le projet.
Il est donc impossible d'avoir 2 schémas portant le même nom dans 2 bases de données différentes… Ce qui enlève tout intérêt à leur utilisation !
Ben c'est surtout que si create schema est un synonyme pour create database c'est plutôt, et surtout, que les schémas n'existent simplement pas.
Donc il n'est simplement pas possible d'avoir des schémas dans une base, donc évidemment pas de schémas dans 2 bases différentes, donc évidemment pas deux schémas portant le même nom dans 2 bases de données différentes.
Et comme dit précédemment ce moteur existe. Mais c'est le rôle du développeur de gérer l'existence de plusieurs moteurs et de choisir le bon suivant les fonctionnalités désirées.
Et tu t'es jamais dit qu'on pouvait vouloir monitorer l'ensemble des programmes ?
Genre si j'ai un log avec une structure unifiée et que j'ai 10 services différents sur ma machine, ben je peux monitorer les 10 de manière unifiée et sortit tous les error sur une période donnée par exemple. Et si je rajoute un 11° service ? Ben ça ne changera rien du tout. Et d'ailleurs je m'en fout du service qu'on vient de rajouter, je veux juste qu'il respecte un tant soit peu une structure correcte qui fait que si mon serveur crash je peux remonter tous les warnings 5 minutes avant. Ha mais attends, comment je sort les warnings et erreurs (mais pas debug, info) de apache, postfix, système, etc sur une plage de temps facilement ? Ben je peux pas.
Tu veux dire qu'on va se fader du xml
Ou pas, faut lire.
éviter d'écrire un parser en awk/perl/cut par programme
Ce serait un grand pas en avant.
Je pense que les gens qui font ça n'aiment tout simplement pas Unix.
Et le premier truc qui manque, immédiatement, c'est le niveau de log (debug, warn, etc).
Hop, faut en rajouter.
Après, standardiser classname/methodname c'est aussi une très bonne chose.
Hop, faut en rajouter.
Le truc c'est qu'on peut continuer comme ça longtemps.
Ha tiens, si j'écrivais classname:methodname
Ha tiens, si j'écrivais classname#methodname
Oups
Mouai… MySQL est par certains aspects bien plus abordable que PostgreSQL. Ce ne veut pas dire que l'un soit meilleur que l'autre mais bon.
De même, si MySQL se trouvait chez tous les hébergeurs c'est bien qu'il répondait à des problématiques que PostgreSQL faisaient surement moins bien (bien peut avoir beaucoup de sens différents…)
[^] # Re: Le fond noir pour les images
Posté par CrEv (site web personnel) . En réponse à la dépêche Firefox 11. Évalué à 6.
Juste pour savoir, c'est quoi un fond noir très foncé, et un fond noir pas foncé par exemple ?
[^] # Re: Protocole adapté ?
Posté par CrEv (site web personnel) . En réponse au journal Google n'est pas notre ennemi (avec des morceaux d'OSM dedans). Évalué à 2.
Non
OSM c'est avant tout de la donnée. De la donnée brut. Il faut alors la rendre (générer la carte). Et là plusieurs serveurs existent.
Ensuite, côté client, ben en général c'est souvent du WMS / WFS / TMS / KML. En dehors de ça y'a pas énormément de choses.
Et les clients sont souvent des clients TMS (tuiles) car c'est quand même simple.
Les clients ne sont pas spécifiques à OSM, loin de là. En général ce sont des clients qui lisent les formats OGC (plus ou moins).
Le problème n'est pas uniquement en temps de rendu. Déjà il y a quand même un côté idiot à vouloir que tout le monde rende la même donnée, ça va un peu à l'encontre d'une mutualisation de moyen et fait du boulot auprès de tout le monde.
Ensuite, je pense que tu sous-estime le temps de dessin d'une (ou plusieurs) tuiles. Si les gens apprécient Google Maps (comme dit dans l'article) c'est parce que ça va vite. Il est illusoire de croire qu'on peut avoir les mêmes performances sans un minimum de prégénération de tuiles.
Bon après c'est pas si blanc/noir, lorsqu'on envoi un kml à afficher à Google il l'envoi sur ces serveurs et le tuile côté serveur plutôt que de le rendre côté client. Idem pour les markers.
Mais concrètement, côté temps de rendu on aura pas de bonnes performances. Et un moteur de rendu c'est pas si léger que ça non plus.
Une tuile vectorielle c'est déjà différent car c'est juste que ce n'est pas une image bitmap qui est envoyée mais une image vectorielle. Une partie du traitement est déjà faite.
Pour présenter un peu les autre problématiques au rendu côté client : le placement des étiquettes de lieux, nom de rue, etc. C'est une opération qui est loin d'être négligeable. Lesquelles afficher. Gestion de conflits. Gestion d'importance. Comment faire pour que leur position ne dépende pas de la vue du client. etc.
[^] # Re: Okay
Posté par CrEv (site web personnel) . En réponse au journal Zino lève 5 millions de dollars en 48h. Évalué à 6.
Je comprends et je compatis.
En effet on devrait écrire "la guerre saymal".
[^] # Re: Okay
Posté par CrEv (site web personnel) . En réponse au journal Zino lève 5 millions de dollars en 48h. Évalué à 2.
Allez, toi qui adore les autre protocoles :
Contrairement à ce que tu penses ce n'est pas entièrement fermé dans du http et du oueb, loin de là.
[^] # Re: Protocole adapté ?
Posté par CrEv (site web personnel) . En réponse au journal Google n'est pas notre ennemi (avec des morceaux d'OSM dedans). Évalué à 3.
Je ne crois pas.
Dans tous les cas le problème de tuiles vectorielles est que ça ne fait plus vraiment un TMS et qu'il faut rendre (dessiner) ces tuiles côté client. Vu que les tuiles vectorielles ne sont pas vraiment standards et que les nombreux clients ne les supportent pas, ça devient malheureusement peu envisageable.
Maintenant rien n'empêcherait d'en générer (ce qui serait il est vrai intéressant côté place et donc bande passante nécessaire, le tout contre un coût d'affichage un peu plus élevé - en terme de puissance demandée)
# .
Posté par CrEv (site web personnel) . En réponse au journal Zino lève 5 millions de dollars en 48h. Évalué à 6.
Bon, tout ça c'est bien joli, mais ça ne nous dit pas
quel est le nouveau multi de samwangoù en est zino ![^] # Re: Protocole adapté ?
Posté par CrEv (site web personnel) . En réponse au journal Google n'est pas notre ennemi (avec des morceaux d'OSM dedans). Évalué à 2.
Bon, je comprends plus. Tu as assez de bande passante ou pas ?
Heu, quelle partie du contenu ? Les données (je crois dans les 250Go) mais qu'en est-il des tuiles ? Si tu veux tout rendre il faut compter dans les 54To, la partie communément visible faisant de l'ordre de 1.2To (http://wiki.openstreetmap.org/wiki/Tile_Disk_Usage)
Héberger une partie de la data tout seul dans ton coin ça va pas servir à grand chose, ce qui compte c'est aussi de pouvoir rendre la tuile (et ça on va pas le faire sur chaque client, d'ailleurs ce serait plutôt idiot car ça voudrait dire que chaque client embarque un serveur de rendu carto) et les perfs seraient assurément catastrophiques.
Mais dans tous les cas, je vois pas bien le rapport avec http dans l'histoire.
Qu'est ce qui est bloquant avec HTTP dans ton histoire et qui ne le serait pas avec un autre protocole ? En quoi un autre protocole résoudrait le problème ?
[^] # Re: Protocole adapté ?
Posté par CrEv (site web personnel) . En réponse au journal Google n'est pas notre ennemi (avec des morceaux d'OSM dedans). Évalué à 2.
Heu, http ou pas si tu n'as pas assez de bande passante … ben t'en as pas assez.
Quel est le rapport avec HTTP ? Tu peux très bien avoir un service http qui te répond une 503 service unavailable lorsque le nombre d'utilisateur maximum autorisé est atteint.
Pas forcément. Le but des CDN est justement contraire non ? En gros le DNS va prendre en compte certains critères pour te diriger vers le bon serveur (entre autre, en général, la localisation géographique afin de te faire servir par un serveur le plus proche possible, mais rien n'empêche d'avoir d'autres critères comme la disponibilité, le temps de réponse, le statut, etc).
Non, c'est juste un exemple. Et la réponse "comment je fais ailleurs" n'y répond justement pas.
Et le truc c'est que HTTP est tout fait pertinent lorsqu'il s'agit de fournir une ressource. Ecrire un client HTTP est simple et si tu veux avoir ta localisation dans ton client IRC ça devient justement simple puisqu'il te suffit d'une url pour que ça fonctionne. Et sur ton super client, comme t'aimes bien la séparation, tu peux simplement lui demander de faire un curl de la bonne url dans un fichier temporaire, ton client irc va alors afficher le fichier image dans et hop, c'est fait. Il est donc où le problème avec HTTP ?
[^] # Re: Protocole adapté ?
Posté par CrEv (site web personnel) . En réponse au journal Google n'est pas notre ennemi (avec des morceaux d'OSM dedans). Évalué à 6.
En fait, je viens de me rendre compte que t'es super fort, comment tu fais, tu as un grep qui tourne en permanence sur les commentaires / journaux pour chopper tout ce qui tourne autour d'http ?
Ha ok, comme ça c'est chaque utilisateur que tu va blinder…
On doit pas avoir la même définition du minitel 2.0 alors.
la "webbisation" n'a pas vraiment de lien avec le minitel, c'est beaucoup plus la centralisation et le fournisseur unique.
OSM n'est pas dans ce cas puisque tu peux très bien récupérer les données et les faire fournir par ton propre service. Donc où est le côté minitel 2.0 ?
Heu, ben pourquoi tu ne le fais pas ?
Oué enfin y'a pas que http. Pour monter en charge, pour avoir des infra redondantes, que tu utilises http ou pas le problème reste sensiblement le même.
Et d'ailleurs tu peux aussi avoir un CDN en P2P, c'est pas du tout incompatible.
Donc où est le problème ?
Maintenant, sans http, comment tu fais pour afficher un plan de localisation sur une page web ? Ok, tu vas me dire que ça devrait pas être dans le web, mais c'est faux. Donc comment tu fais ? Tu fais un nouveau protocole et tu l'implémente dans ton navigateur ?
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 3.
Ca dépend vraiment des cas.
Un projet qui aurait par exemple sa conf en yaml, qui sérialiserait un certain nombre de données en json (stockées par exemple en base, renvoyées au client web, etc), voir même qui boufferait du json directement depuis postgresql, et qui aurait aussi de l'xml à certains endroit, juste pour pouvoir utiliser du xsl et faire des transformations intéressantes ne me choque pas plus que ça.
La critique était valable, il me semble, il y a quelque temps, lorsque les libs n'étaient pas là.
Mais si on a un parseur/lib correct pour les différents format alors il n'y a aucun soucis, d'ailleurs à ce moment le format devient quasiment transparent. Par exemple, dernièrement j'ai utilisé gson pour sérialiser différentes informations, ben y'a pas à chier c'était bien plus rapide que de le faire en xml.
D'ailleurs, json a un avantage certain sur xml : plus personne ne fait d'ajax, quasiment tout le monde fait de l'ajaj (oué on pourrait aussi juste dire aj), les données sont de plus en plus envoyées / reçues en json. L'XML était peut-être une bonne idée, mais lorsqu'on voit le coup d'un parse xml / xsl côté client, on oublie vite.
Et donc si on dialogue en json, on a tout intérêt à stocker / cacher / etc les données en json pour pouvoir dialoguer à moindre coût.
[^] # Re: Le parti pirate, ça sert à rien
Posté par CrEv (site web personnel) . En réponse au journal Le parti pirate cherche des candidats. Évalué à 2.
Je pense que t'as pas vraiment compris mon message, c'était une figure de style si tu préfère. Je sais très bien qu'on peut trouver la position d'EELV sur tous ces sujets.
Mais le commentaire initial était du genre "le parti pirate il s'occupe rien que de l'internet donc il ne peut pas avoir de position sur le reste". La logique voudrait que ce soit la même chose pour les partis centrés sur un sujet précis. Ou pas justement. EELV montre qu'un parti qui réunit des personnes sur un sujet précis (façon de parlé) peut avoir aussi des positions sur le reste.
Ce n'est surement pas encore le cas du parti pirate mais rien ne l'empêche en réalité.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 6.
Non, ce qu'il dit est que le moment de gloire d'XML c'était il y a 10 ans. Maintenant c'est has been dans la majorité des cas (j'exagère un peu, mais au moins il ne devrait pas y avoir d'ambiguïtés)
Heu… aucun rapport entre administration et bon ou mauvais choix. D'ailleurs, peu de différence au final entre administration et "grand compte" ou ssii, c'est en général plutôt mauvais dans tous les cas :-(
Le problème de SOAP c'est juste que c'est imbitable comme techno et que beaucoup tente à tout prix de l'éviter et s'en portent beaucoup mieux (à moins de vouloir jouer uniquement avec des générateurs de code dans tous les sens)
Oui pour ce point. Malheureusement vu le nombre de fois où on touche du XML sans avoir de schéma ou dtd, le typage ne sert pas à grand chose…
Oui, il faudrait.
XML a de bons avantages, mais il à l'inconvénient majeur d'être implanté. Il est devenu, de fait, un standard dans la sérialisation texte. Donc la majorité des gens utilisent, lorsqu'ils veulent du texte, du .ini ou dès que le .ini ne suffit pas, du xml. D'ailleurs sans forcément réfléchir.
Et, par méconnaissance essentiellement, les gens ne vont pas chercher plus loin, des parseurs existes, et hop xml.
Pour le côté méconnaissance : si je prend les développeurs que je connais, il n'y en a pas la moitié qui a déjà entendu parlé de YAML par exemple.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 4.
oulala, je crois que c'est l'heure de la camomille…
Ca tombe bien j'ai même pas inutilé.
Justement, ce que j'en dis c'est que la majorité des usages d'xml sont mauvais.
Ha mais le xml me plait. Mais surtout pas n'importe où.
Je pense que si, par certains côtés, c'est un effet de mode.
Il y a un temps, tout le monde faisait du xml, pour tout et n'importe quoi. Là c'était vraiment la mode. D'ailleurs il n'y a qu'à voir un certain nombre de frameworks java qui utilisent beaucoup trop le xml pour s'en rendre compte.
Aujourd'hui on l'utilise beaucoup moins et c'est beaucoup mieux (enfin sauf dans pas mal de projets java qui n'évoluent malheureusement pas dans le bon sens). On arrive alors à un usage à peu près raisonné et intelligent de l'xml. Mais c'est pas encore le cas partout.
[^] # Re: Le parti pirate, ça sert à rien
Posté par CrEv (site web personnel) . En réponse au journal Le parti pirate cherche des candidats. Évalué à 3.
Ha oui, un peu comme :
Quel va être le programme de "EELV" sur l'avortement ? Sur la guerre en Syrie ?
Sur l'écologie ?(ok, ça c'est bon) Sur le chomâge ? Sur les retraites ? Sur l'euthanasie ? Sur l'Union Européenne ? Sur la fiscalité ?[^] # Re: Le début de la fin ?
Posté par CrEv (site web personnel) . En réponse au journal Google la croque-t-il ?. Évalué à 2.
Ok, donc si j'ai bien compris ton message : tu n'en as strictement aucune idée, c'est bien ça ?
Allez, encore un petit effort et la prochaine fois tu les placera au bon endroit ;-)
[^] # Re: ouah!
Posté par CrEv (site web personnel) . En réponse au journal Google la croque-t-il ?. Évalué à 6.
Ha bon ? Et pourquoi donc ?
Même pas vrai, j'ai un macbook. De toute façon on voit bien qu'en fait vous êtes juste jaloux de ne pas pouvoir vous offrir de produit Apple.
Salauds de pauvre !
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 5.
Oué enfin (l'écosystème) java l'utilise toujours pour tout et n'importe quoi. Par exemple entre une configuration de servlets dans un web.xml et un module servlet de guice mon choix est très vite fait (en plus du fait que c'est beaucoup plus puissant…)
ça tombe bien c'est souvent ce qui lui est reproché. Il ne faut pas confondre le fait qu'ils l'utilisent et la pertinence de son usage.
Oué, sauf qu'on fait absolument pas du maven pour le côté xml. Si on pouvait d'ailleurs faire du maven sans la lourdeur intrinsèque à l'xml on s'en porterait beaucoup mieux.
Oui mais le problème c'est que dans ces exemples il n'y en a aucun qui donne envie de faire du xml.
Pour odf/ooxml et rss/atome c'est bien les seuls cas que je trouve intéressant. Mais le reste…
[^] # Re: Intérêt ?
Posté par CrEv (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 3.
Sur le principe oui.
En pratique, non, surtout pas.
Surtout pas, car c'est dans ce genre de quête qu'on se perd souvent, qu'on perd beaucoup de temps et au final on a rien. Surtout si on vise cette perfection initialement.
Il y a pas mal de maximes sur le sujet, la plus connue étant "le mieux est l'ennemi du bien".
On peut ensuite parler de worse is better.
Et dans les faits on se rend compte que, souvent, les solutions moins optimales mais plus souples fonctionnent mieux et sont plus adoptées car au final elles correspondent à beaucoup plus de cas, et pour les cas limites sont suffisamment malléables pour s'adapter.
Il n'y a qu'à voir aussi les xkcd (ok, toujous le même) qui est balancé ci et là sur les standards).
Oué je sais, j'ai tiqué sur un point de détail, mais malheureusement ce type de raisonnement "autant faire parfait tout de suite" est extrêmement contre-productif, c'est même un véritable fléau en entreprise et plus généralement quelque soit le projet.
[^] # Re: Wahou
Posté par CrEv (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 8.
Ben c'est peut-être là, au fond, le vrai problème…
[^] # Re: Quitte à rester dans le gore
Posté par CrEv (site web personnel) . En réponse au journal MySQL est une bouse immonde. Évalué à 5.
Ben c'est surtout que si create schema est un synonyme pour create database c'est plutôt, et surtout, que les schémas n'existent simplement pas.
Donc il n'est simplement pas possible d'avoir des schémas dans une base, donc évidemment pas de schémas dans 2 bases différentes, donc évidemment pas deux schémas portant le même nom dans 2 bases de données différentes.
[^] # Re: Hum
Posté par CrEv (site web personnel) . En réponse au journal Chronique d'un flop annoncé. Évalué à 2.
Et moi qui croyait qu'on était déjà passé au tout numérique…
[^] # Re: Mauvaise méthode de développement ?
Posté par CrEv (site web personnel) . En réponse au journal MySQL est une bouse immonde. Évalué à 3.
Et comme dit précédemment ce moteur existe. Mais c'est le rôle du développeur de gérer l'existence de plusieurs moteurs et de choisir le bon suivant les fonctionnalités désirées.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 2.
Et tu t'es jamais dit qu'on pouvait vouloir monitorer l'ensemble des programmes ?
Genre si j'ai un log avec une structure unifiée et que j'ai 10 services différents sur ma machine, ben je peux monitorer les 10 de manière unifiée et sortit tous les error sur une période donnée par exemple. Et si je rajoute un 11° service ? Ben ça ne changera rien du tout. Et d'ailleurs je m'en fout du service qu'on vient de rajouter, je veux juste qu'il respecte un tant soit peu une structure correcte qui fait que si mon serveur crash je peux remonter tous les warnings 5 minutes avant. Ha mais attends, comment je sort les warnings et erreurs (mais pas debug, info) de apache, postfix, système, etc sur une plage de temps facilement ? Ben je peux pas.
Ou pas, faut lire.
Ce serait un grand pas en avant.
Lapincompris le rapport.
[^] # Re: Le but est de standardiser le contenu des logs
Posté par CrEv (site web personnel) . En réponse à la dépêche Projet Lumberjack. Évalué à 7.
Et le premier truc qui manque, immédiatement, c'est le niveau de log (debug, warn, etc).
Hop, faut en rajouter.
Après, standardiser classname/methodname c'est aussi une très bonne chose.
Hop, faut en rajouter.
Le truc c'est qu'on peut continuer comme ça longtemps.
Ha tiens, si j'écrivais
classname:methodnameHa tiens, si j'écrivais
classname#methodnameOups
[^] # Re:
Posté par CrEv (site web personnel) . En réponse au journal MySQL est une bouse immonde. Évalué à 3.
Mouai… MySQL est par certains aspects bien plus abordable que PostgreSQL. Ce ne veut pas dire que l'un soit meilleur que l'autre mais bon.
De même, si MySQL se trouvait chez tous les hébergeurs c'est bien qu'il répondait à des problématiques que PostgreSQL faisaient surement moins bien (bien peut avoir beaucoup de sens différents…)
Après, on peut faire des choses sympa tout de même avec MySQL, genre https://developers.google.com/cloud-sql/