J'aurais même envie de proposer que le module JTiles ne stocke plus rien du tout en cache, car on peut le remplacer par une requête à un proxy cache local :
Oui car : - il existe bien Squid pour Windows qui gérera efficacement le cache et le gardera sous contrôle (il peut même stocker son cache sous forme compressée, mais cela demande un peu plus de travail du processeur). - JOSM peut être paramétré pour faire ses connexion internet via un proxy : il n'y a qu'à utiliser ici alors un serveur local http://127.0.0.1:8000/ (si le serveur Squid local est configuré pour écouter le port TCP 8000) - il existe d'autres utilitaires sous Windows (je ne vais pas en donner la liste) implémentant un proxy cache "transparent" qui sera utilisé alors pour filtrer les accès par TOUS les navigateurs ou applications clientes, et leur donner alors un cache commun : ces applications (comme les navigateurs) n'ont plus alors qu'à être paramétrées pour que leur cache soit réduit au strict minimum, par exemple le cache IE par défaut est *beaucoup* trop grand lui aussi, prenant par défaut plus de 20% de l'espace libre du disque dur où est stocké le profil utilisateur ce qui peut faire là encore des dizaines de gigaoctets, cependant il sait aussi faire le ménage des fichiers obsolètes et prévenir aussi le remplissage excessif du disque dur). Certains de ces utilitaires proposent avec des filtres contre les bandeaux de publicité, certains cookies traceurs (bien que ces fonctions soient plutôt assurées maintenant par les antivirus qui mettent en place eux aussi leur propre proxy transparent.... mais malheureusement sans gestion d'un cache web paramétrable pour les requêtes HTTP) Il ne me semble pas que Squid sous Windows puisse être paramétré comme un cache complètement transparent (car HTTP 1.0, contrairement à HTTP 1.1, n'oblige pas un navigateur à effectuer sa requête HTTP avec un paramètre "Host:", et certains services web ne sont pas en HTTP 1.1 ; si le proxy est utilisé comme cache transparent, il devra alors écouter tous les adresses IP pour les requête HTTP à filtrer, ce qui nécessite des privilèges spéciaux et l'installation du cache en tant que filtre intégré au pare-feu des interfaces réseaux, et que ces interfaces soient activées pour utiliser le pare-feu...) En attendant le cache JTiles de JOSM ne tient aucun compte des paramètres HTTP standard de gestion du cache (comme "Cache-Control:" et les dates d'expiration). C'est à mon avis encore une ébauche juste faite un peu dans l'urgence pour éviter de trop solliciter les serveurs TMS juste en "glissant" la carte, et pour que le glissement de la carte ou le zoom avant puis arrière puisse réafficher rapidement les tuiles déjà chargées juste avant avec une réactivité suffisante. L'idée d'utiliser un proxy cache local (mais externe à l'application) serait une solution, mais l'application JOSM saura toujours mieux qu'un proxy comment elle compte utiliser le cache et ce qu'il est pertinent ou pas de garder en cache (Squid par exempel va garder en cache plus de choses parmi les métadonnées, JTiles ne conserve actuellement QUE les ETag). Et c'est pour ça qu'il faudrait l'améliorer pour qu'il gère son cache de façon plus intelligente et sans avoir à recourir à l'installation d'un cache externe sur un poste client. Si on veut que JOSM soit simple à utiliser pour tout le monde, JTiles doit pouvoir tourner nativement et automatiquement sans que les utilisateurs n'aient à le désactiver ni à faire la purge eux-même de son cache local. A ce sujet, j'ai commencé un bout de code destiné à remplacer le code Java existant : comme je l'ai expliqué j'utilise pour le stockage une série de sous-dossiers (jusqu'à 256, arbitrairement, bien que les navigateurs web souvent n'en utilisent que 4), et en stockant les fichiers d'après l'URL complète de la ressource mise en cache, et en déterminant le numéro de sous-dossier à utiliser dans le cache avec un simple hachage de l'URL. String.hash() semble suffire, même si on pourrait utiliser un hachage plus efficace encore (MD5 est très rapide) pour distribuer plus équitablement les fichiers dans les sous-dossiers du cache. Dans ce cas, il y aura un cache commun pour TOUS les serveurs de tuiles, tous les niveaux de zoom, et une gestion de type LRU pour aider à faire le ménage et garantir un volume plafond de stockage (Cela sera très utile pour les utilisateurs de tablettes par exemple, dont le stockage local est limité car sans disque dur mais avec un petit SSD de 32 Go pour TOUTES les applis et l'OS !) Le code fera aussi attention à éviter de prendre toute la place libre, il aura un seuil minimum d'espace libre à garder sur le disque (je pense que ce sera par défaut quelque chose comme le plus grand parmi: 1 Go (?) ; 2% de la taille totale du volume ; 5% de son espace libre au moment du test ; ces valeurs par défaut sont à étudier avant même d'offrir un moyen de les régler dans l'UI des préférences) et qu'il s'obligera à faire plus de ménage si ce n'est plus le cas, même si cela veut dire que le cache local sera beaucoup plus petit que la taille maximum prévue initialement (idéalement il devrait alerter l'utilisateur quand le cache local ne peut plus contenir un minimum de l'ordre de 32 Mo car JOSM devrait alors télécharger trop de tuiles : cette alerte peut aider l'utilisateur à faire le ménage ailleurs sur son disque). Le 5 février 2013 07:16, Romain MEHUT <[email protected]> a écrit : > Merci pour ces réponses très détaillées ;) > > Et bientôt je me poserai sans doute aussi la question pour Linux. _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
