Malheureusement non, ce n'est pas juste une base de données, c'est aussi un site web (un client OSM pour client HTTP) et un protocole (que le site utilise pour se connecter à la base de données).
Il existe des clients standalone pour OSM, il existe aussi une documentation du protocole. Qui est bloaté, parce que ce n'est pas un protocole de couche application, c'est un protocole par-dessus HTTP (en bullshit moderne on appelle ça une API, mais si on était honnête on appellerait ça un protocole de couche 8 (ou 5 dans le modèle TCP/IP) over HTTP). Qui dit protocole bloaté dit implémentations bloatées (ben oui les devs des clients standalone vont pas se faire chier, ils importent direct les libs HTTP juste pour utiliser le minimum que demande l'API), ce qui explique que les clients standalone pour OSM soient tout pourris (en tout cas la dernière fois que j'ai testé il n'y en a pas un qui arrivait à la cheville du client web en terme de features et/ou de perfs).
On pourrait faire un service de cartographie qui utilise un protocole simple, qui utilise juste le minimum en terme d'overhead pour lancer des requêtes et télécharger des tuiles. Dont les évolutions sont le résultat d'une concertation entre les acteurs qui l'utilisent plutôt que des décisions unilatérales que l'acteur unique peut se permettre parce qu'il contrôle à la fois le service, le protocole et le client utilisé par 99% des gens et fait des mises à jour des 3 à la volée. Qui utilise un format d'URL spécifique qui renvoie vers le bon client quand on clique dessus. Mais ça demande d'écrire des RFC, d'en discuter, de les faire valider, c'est long, c'est chiant, on a envie de releaser vite, peu importe si on perdra plus sur le long terme que le temps gagné sur le moment.
[^] # Re: 256Mo
Posté par eingousef . En réponse au journal Tout cela me fatigue.... Évalué à -1.
Malheureusement non, ce n'est pas juste une base de données, c'est aussi un site web (un client OSM pour client HTTP) et un protocole (que le site utilise pour se connecter à la base de données).
Il existe des clients standalone pour OSM, il existe aussi une documentation du protocole. Qui est bloaté, parce que ce n'est pas un protocole de couche application, c'est un protocole par-dessus HTTP (en bullshit moderne on appelle ça une API, mais si on était honnête on appellerait ça un protocole de couche 8 (ou 5 dans le modèle TCP/IP) over HTTP). Qui dit protocole bloaté dit implémentations bloatées (ben oui les devs des clients standalone vont pas se faire chier, ils importent direct les libs HTTP juste pour utiliser le minimum que demande l'API), ce qui explique que les clients standalone pour OSM soient tout pourris (en tout cas la dernière fois que j'ai testé il n'y en a pas un qui arrivait à la cheville du client web en terme de features et/ou de perfs).
On pourrait faire un service de cartographie qui utilise un protocole simple, qui utilise juste le minimum en terme d'overhead pour lancer des requêtes et télécharger des tuiles. Dont les évolutions sont le résultat d'une concertation entre les acteurs qui l'utilisent plutôt que des décisions unilatérales que l'acteur unique peut se permettre parce qu'il contrôle à la fois le service, le protocole et le client utilisé par 99% des gens et fait des mises à jour des 3 à la volée. Qui utilise un format d'URL spécifique qui renvoie vers le bon client quand on clique dessus. Mais ça demande d'écrire des RFC, d'en discuter, de les faire valider, c'est long, c'est chiant, on a envie de releaser vite, peu importe si on perdra plus sur le long terme que le temps gagné sur le moment.
*splash!*