Règle de distance directement dans Cesium

Je ne voudrais pas paraître hérétique mais, dans un 1er temps, ne serait-ce pas plus simple de calculer la distance pour soi directement dans Cesium ?

Après tout le calcul n’est pas vraiment lourd actuellement, le plus difficile c’est de récupérer 100k certifications (100k couples de deux octets, un pour l’émetteur et un pour le récepteur, donc 200ko) et les référents (je n’ai pas le nombre, mais je vais le négliger vu sa faible valeur par rapport aux certifications).

C’est assez rapide à obtenir d’un nœud RPC, quid d’un indexeur ?

Et se réserver les solutions plus durables pour plus tard, quand le besoin s’en fera ressentir ?

Je pense partir sur cette solution sauf avis contraire. Et directement à partir d’un nœud RPC sauf si quelqu’un justifie l’utilisation d’un indexeur à la place.

Je suis d’avis d’utiliser au max les données du storage via RPC dès que possible, et squid uniquement pour ce qui n’est pas accessible via duniter.
Plus résiliant, plus réactif.

Oui, on en avait parlé pendant une visio :

mais on n’a pas avancé sur cette idée qui semble en effet assez simple.

Pour limiter le traffic réseau, il faudrait transférer la liste des identités membres (liste d’entiers) et la liste des certifications actives (liste de couples d’entiers) de manière compacte pour atteindre les 200ko dont tu parles.

Parce que actuellement

query ActiveCerts {
  certs(condition: {isActive: true}) {
    nodes {issuer{index, isMember} receiver {index, isMember}}
  }
}

en est très loin, ça retourne en 3.5 secondes un gros 1.3Mo.

On peut faire un computed field sur squid qui ne renvoi que les données désirés.

Oui, et idéalement en binaire plutôt qu’en texte.

Oui d’ailleurs je comptais 2 octets par couple, mais actuellement il faut 4 (deux octets par ID de membre). Donc plutôt 400ko en binaire et sans compression.

J’ai pu avancer sur cette feature.

Voici le rendu :

Content que ça vous plaise :slight_smile: par contre j’ai mis un bouton plutôt que de lancer le calcul automatiquement, afin de laisser les nœuds RPC tranquilles par défaut.

Toute la row est elle clickable ?

Non juste l’icône.

J’ai ajouté de l’avancement plus progressif :

Je pense que c’est bien si toute la row est clickable, en terme d’ux j’essaie de faire ça partout.
Qu’on comprenne mieux que c’est clickable, Les gens peuvent vouloir cliquer sur le wording de la row.

Oui mais il y a deux choses cliquables : le bouton de calcul de la distance, et le point d’interrogation qui mène à l’aide en ligne :

Pour moi ce n’est pas gênant d’avoir la row clickable pour lancer le calcul de distance, et le point d’interrogation à l’intérieur pour ouvrir l’aide, tant que sa hitbox est suffisamment large..

Le point d’interrogation à une bonne affordance. On devine facilement en le voyant qu’on peut cliquer dessus.
L’icone de calculatrice, beaucoup moins. Le fait que toute la row soit cliquable aide à le deviner, sur web le curseur change, sur mobile le splash apparait si on reste un peu longtemps dessus.

Bon c’est du détails.

J’ai suivi tes conseils, voici le rendu (à ceci près que la capture de la vidéo empêche de voir que le pointeur devient une main) :

La branche est rebasée sur tes développements de gestion de l’identité.

Relu, testé et mergé :+1: