Dans la réflexion de créer une application dédiée à la manipulation de photos et de vidéos se pose invariablement la question des vidéos HD, FHD et UHD. La taille de ce genre de vidéo, pour conserver une qualité de restitution optimale, est assez conséquente.
Le problème ici dans nebule c’est la vérification systématique de la validité du contenu d’un objet manipulé, c’est à dire le re-calcul de son empreinte cryptographique. Si la librairie nebule mémorise le temps d’une session un objet vérifié, dans un cache, ce qui peut déjà présenter un problème de sécurité, il faut cependant toujours faire cette prise d’empreinte au moins une fois.
Par exemple l’empreinte SHA256 d’un fichier de 1,6Go va nécessiter environ 30s sur un disque dur à plateaux normal. La consommation de temps vient principalement de la lecture du support et non du calcul cryptographique. Et la prise d’empreinte cryptographique est un calcul relativement simple…
Il peut en être de même avec les liens qui nécessitent une vérification de signature de type RSA ou équivalent. Ce calcul en cryptographie asymétrique est beaucoup plus long rapporté à la quantité de données. Si un lien ne faire que quelques kilo-octets tout au plus, le nombre de liens à vérifier pour un seul objet peut être potentiellement gigantesque. Au cours du développement des applications de nebule il n’est pas rare de devoir nettoyer à la main les liens de la bibliothèque parce qu’il y en a plus de 80.000 … soit systématiquement 80.000 lien à lire et à vérifier. Là aussi un cache des liens déjà validés dans la session est en place pour accélérer le travail mais ce n’est pas toujours suffisant.
Une possible résolution de ce problème peut être de changer de disque et de passer sur SSD, ou de nettoyer sévèrement les liens utilisés. Mais ces deux cas sont extrêmes et pas toujours réalisables.
Une autre solution peut être envisageable dans le cas de machines de relais ou de partage d’informations en particulier. Comme on l’a vu dans l’article Frontal et relai d’information verrouillé en écriture, il est possible d’avoir des serveurs en lecture seule en activant l’option de lecture seule ou en figeant le système de fichiers. Cela pose des contraintes particulières sur la synchronisation des objets et des liens et sur le fait qu’ils doivent être vérifiés à un moment ou à un autre. Dans ce cas on peut coupler une option de non vérification des objets et des liens avec une option de lecture seule.
Avec cet exemple une entité peut toujours d’authentifier afin d’accéder à du contenu protégé mais ne pourra réaliser aucune action.
On peut imaginer aussi que l’application de mise à jour (upload) peut être autorisée à mettre à jours des liens et des objets en les vérifiant et ainsi avoir un serveur partiellement en lecture seule.
Donc il serait possible d’avoir un serveur de relai d’information en lecture seule uniquement mais avec un fonctionnement accéléré.
Ceci n’est pas implémenté actuellement.