Le lien étant la partie essentielle du partage de l’information, il doit être définit pour répondre exactement à ce rôle. C’est un des trois piliers de Nebule.
Par essence, sa définition se doit aussi d’être précise et universelle.
Étudions quelques cas…
En partant sur le modèle de lien avec objet méta par rapport au lien et non à l’objet source, on se rend compte que c’est un compromis.
L’Uniform Resource Identifier (URI) est une chaîne de caractères permettant l’identification d’un objet de façon univoque et permanente.
(Wikipedia – Licence CC BY-SA v3.0)
L’empreinte d’un objet réalisée au moyen d’une fonction de hash cryptographique est un URI.
(Suite du post Liens simples ou doubles?)
Le problème semble insoluble avec les liens simples pour partager efficacement de l’information sans être dépendant d’un nÅ“ud populaire. Que peut-on faire pour ré-équilibrer le sens de transfert des liens?
La notion d’arborescence convergente est une propriété intéressante, mais gagnerait à fonctionner dans les deux sens. C’est à dire d’être à la fois convergente vers de gros nÅ“uds du réseau, est d’être en même temps divergente en partant de ces gros nÅ“uds. Continuer la lecture de Liens doubles
Si un lien vers un objet ne contient pas de méta-données, il n’apporte pas d’informations sur le traitement, l’utilisation de cet objet. L’objet doit donc contenir le nécessaire pour que l’on puisse identifier son type, et par extension sa façon de l’utiliser. Il doit être différencié. Si le lien contient des métas, l’objet peut être indifférencié, ce sont les métas du lien qui détermineront le traitement de l’objet.
L’important, c’est qu’au moment du traitement, les données de l’objet aient été différenciées.
Continuer la lecture de Objet différencié ou indifférencié
L’approche Big data est intéressante en plusieurs points, dont notamment le concept des 4 V.
L’expression Big data désigne des ensembles de données qui deviennent tellement gros qu’ils en deviennent difficiles à travailler avec des outils classiques de gestion de base de données. Continuer la lecture de Big data et concept des 4 V
Le marquage du temps est un élément primordial dans l’échange d’informations.
Un lien créé vers un objet doit contenir une marque de temps de cette création. Cet horodatage ne semble pas utile au première abord, mais il est nécessaire si l’on veut ensuite pouvoir casser ce lien.
Une information, et donc un lien, doit être considéré comme non effaçable une fois créé. Cette information ayant été à priori diffusée, on en perd le contrôle, et donc la capacité de suppression. A défaut d’être effacé, cette information doit être désactivable. Dans le cas du lien, on le désactive aussi. Cette désactivation sera à son tour diffusée, et de la même façon on en perdra le contrôle.
La création d’un lien doit être vue comme la création de l’objet lien doublé d’une opération de signature cryptographique de ce même objet lien. L’entité validant ainsi le lien de façon forte, sa désactivation doit aussi être faite par une méthode forte, c’est à dire doublée d’une opération de signature cryptographique (par le même signataire en fait).
La désactivation doit aussi être horodaté, pour deux raisons. La première pour simplement savoir quand elle a été faite. La deuxième pour que l’on puisse sans ambiguïté savoir si cette désactivation intervient bien après la création. Et ainsi de suite, le lien ou toute information peut être validé et invalidé plusieurs fois de suite dans le temps.
Le marqueur de temps doit être couvert par la signature. Il doit être systématiquement présent avec la signature.
Nous avons besoin aujourd’hui de tous avoir le même espace de temps pour pouvoir communiquer et travailler ensemble. Cette état de fait pose déjà le problème de la référence de temps, nous devons avoir la même heure.
Mais cette nécessité de tous travailler avec la même heure se heurte aux grandes distances et les décalages horaires que cela implique bien que les communications n’en soient que peu affectées.
Et comment fait-on si, indépendamment du décalage horaire, deux entités décident volontairement de ne pas travailler avec la même référence de temps? Et si en plus l’unité de temps est différente?
Une première approximation de ce que à quoi on peut s’attendre se pose sous la forme d’une équation du premier degré :
Tv = a Ti + b
Le temps vu Tv est calculé par rapport au temps interne Ti affecté d’un coefficient a et corrigé par un décalage b.
Dans la vraie vie, il faut beaucoup d’efforts pour approcher une synchronisation parfaite entre deux entités. A l’échelle d’un pays, c’est impossible, on se contente de quelques secondes voir quelques minutes de décalage horaire entre toutes les entités. Et chaque horloge interne souffrant d’une dérive plus ou moins grande, il faut régulièrement calculer et compenser cette dérive. Même tous d’accord, nous avons bien notre coefficient a et notre décalage b.
Et encore, on considère là que l’horloge interne de chaque entité est stable dans le temps…
On peut continuer à essayer d’être tous calés sur la même référence de temps. Ou on peut prendre le problème en sens inverse, prendre en compte que chacun a son heure de fonctionnement propre, et calculer quand nécessaire la correction du datage des objets.
Il faut cependant dans ce cas qu’un ou plusieurs liens existent entre les différentes entités, liens qui permettent de calculer de décalage de temps. C’est le rôle du marqueur de temps qui date et signe un objet généré par une entité, objet qui contient sa date de création. Ou du marqueur de temps qui génère régulièrement des objets horodatés que toutes entité peut dater/signer.
Cette méthode nécessite cependant une certaine coopération entre les deux entités. Il y a peut-être moyen de disposer d’une méthode proche par signatures d’objets communs et qui marcherait même en mode non coopératif.
La suite au prochain épisode…
Quand dans un objet A il est fait référence à un autre objet B au moyen d’une URL, cela correspond à la mise en place d’un lien entre ces deux objets A et B. Ce lien est par défaut à sens unique, il désigne un autre objet.
Mais un lien n’existe jamais seul dans le monde réel, il est souvent accompagné d’informations complémentaires. Ces informations complémentaires permettent de préciser la façon dont on accède et/ou on utilise l’objet désigné. Cela s’appelle une méta-donnée, une donnée sur la donnée (raccourci en méta).
Cette méta s’applique-t-elle à l’objet désigné? Ou au lien?
Actuellement, le lien (ou raccourci) permet de pointer ou désigner un fichier, une page, etc… Il est positionné à un endroit de l’arborescence ou d’internet et pointe vers une cible ailleurs dans la même arborescence, dans une autre arborescence, ou sur internet.
Ce lien contient forcément la localisation univoque d’une cible, mais peut aussi en option contenir des informations sur la cible, une façon particulière de l’utiliser, de la traiter, etc… En clair, des méta-données sur le lien proprement dit. Continuer la lecture de Liens simples ou double?
La gestion de l’information peut, sur un premier niveau, se baser sur trois axes :
J’en vois beaucoup, et encore aujourd’hui, qui cherchent désespérément la meilleur arborescence possible pour ranger tous les documents du département. Ça part d’un bon sentiment, faire en sorte que les fichiers soient positionnés au bon endroit dans l’arborescence complexe de façon à ce que tout le monde puisse tout retrouver rapidement et facilement.
Certe l’effort est louable, mais encore faut-il que cette arborescence soit comprise par tout le monde. Et qu’elle de soit pas modifiée régulièrement lorsqu’il arrive des documents qui ne tiennent pas de places convenables dans l’arborescence actuelle, signe flagrant qu’elle n’est pas adaptée…
La modification de l’arborescence n’est pas un problème en soi si c’est pour rester au plus près des besoins, mais les humains ont la fâcheuse tendance à mémoriser l’emplacement (le chemin) plutôt que la logique d’accès. D’autant plus que chacun a sa propre logique pour le rangement des documents en fonction de ses besoins.
Bref, au final, au lieu d’être une aide, beaucoup s’y perdent…
Mais au fait, pourquoi en est-on arrivé là ?
Dans la dernière revue MISC(1), en marge du dernier article, on trouve un petit descriptif rapide des modèles DAC, RBAC et OrBAC.
L’évolution de ces modèles tend vers la création d’un langage à part entière que l’on peut traduire vers nos langages humains, et vice-versa.
Et ce langage n’est autre qu’une forme de lien entre deux objets.
Un projet intéressant sur le principe :
http://tech.chambana.net/projects/commotion
A première vue, cela ne concerne pas l’échange de données à proprement parler mais plutôt la mise en place d’un réseau complètement décentralisé.
Il y a comme un écho… aux travaux originels d’internet!
Ce serait un réseau auto-organisé, capable de se monter rapidement sans infrastructure en dur, avec peu de moyens ou lors de catastrophes, voir en milieu hostile.
Comment retrouver rapidement les objets récemment créés?
La méthode habituelle, la première à laquelle on pense, c’est de parcourir l’intégralité des objets afin de vérifier le(s)quel(s) sont récents.
Sous nebule, les objets sont référencés par leur empreinte. Ça ressemble quelque part au référencement des fichiers par des inodes sur les systèmes de fichiers UNIX. Continuer la lecture de Fichiers et chemins
Petite déconvenue pour une société Suisse au USA.
Non qu’elle ai fait quelque chose de mal, mais dans sa ferme de serveurs dûment monnayée à ses clients se trouvait un site web utilisé par des personnes peu fréquentables.
Résultat, descente du FBI qui repart avec la baie de serveurs…
Et hop, offline tous les autres clients légitimes !
Aujourd’hui, quelle société qui nécessite plus d’un serveur n’a pas mis en place une baie disque type SAN avec une solution de virtualisation?
On se retrouve avec une machine virtuelle qui tourne quelque part dans la ferme de serveurs, et dont les disques systèmes sont stockés quelque part sur le SAN en RAID éclaté sur plusieurs disques physiques…
Le FBI n’a pas dû pouvoir disposer rapidement de l’information concernant la localisation physique réelle du serveur et de ses disques :-(
Liens :
– http://pro.clubic.com/it-business/hebergement-site-web/hebergement-dedie-internet/actualite-430188-fbi-saisit-serveurs-usa-dizaines-sites-hors-service.html
– http://bits.blogs.nytimes.com/2011/06/21/f-b-i-seizes-web-servers-knocking-sites-offline/?smid=tw-nytimesbits&seid=auto
La façon dont les objets sont liés entre eux est importante. Mais il y a aussi la façon dont les entités sont liées entre elles. Les liens entre ses entités suivent-ils la forme des liens entre objets? A priori oui, puisque une entité est avant tout un objet aussi.
Un autre problème qui lui est spécifique aux entités, c’est la localisation. C’est à dire la façon de retrouver une entité dans un vaste réseau. C’est le rôle de ce que l’on appelle un annuaire. Cela doit être vu comme un système similaire au DNS dans sa fonction.
Suite à un article fort intéressant sur un blog, je me rends compte que le problème est plus difficile qu’il n’en a l’air.
Pour résumer et pour reprendre l’article de Wikipedia sur le triangle de Zooko, un système de nommage ou un système d’annuaire doit :
1: Secure, doit être sécurisé.
2: Memorable, doit être facilement mémorisable par un être humain.
3: Global, doit garantir l’unicité.
Jusque là , rien de nouveau sous le soleil, sauf que l’article précise aussi que l’on ne peut satisfaire qu’à deux des trois conditions simultanément au maximum.
On peut ajouter aussi, en autre (cf premier lien), l’aspect stabilité dans le temps. Je pense que, l’entité pouvant être mobile, seule la stabilité dans le temps de l’unicité de l’entité est à assurer. Or, c’est déjà le rôle de l’identifiant unique (clé privé) de l’objet entité.
Je serais bien tenté de penser que pour Nebule, l’aspect globale est le moins « nécessaire ». Quoique l’aspect user friendly peut être dévolu à une autre fonction, dans ce cas l’annuaire s’assure juste de faire le lien entre entité et ressources physiques (réseau). A voir…
Je ne suis pas très familiarisé avec les problèmes légaux liés au vote électronique, donc sans le petit bout de papier. Mais il semble que les polémiques actuelles sur les équipements testés tiennent surtout à la façon dont ceux-ci sont conçus.
Et surtout, les critiques tournent autour de l’utilisation de logiciels fermés, donc dont le fonctionnement ne peut être vérifié par tout citoyen. Comment peut-on être sûr que la machine de plante pas, comptabilise bien les votes, et surtout les comptabilise bien à la bonne personne? Voir, comment vérifier que personne n’a faussé le score (nécessite un re-décomptage)?
Suivant quelques articles que l’on retrouve sur le net :
– http://www.cnetfrance.fr/…
– http://www.clubic.com/…
la société qui édite la solution Dropbox a été contrainte de modifier la description de son produit phare.
En cause, la sécurisation réelle des données que l’on confiait à ses serveurs. On a à l’origine un chiffrement AES 256 bit dont seul le client a les clés pour ses fichiers, c’est à dire donc qu’il est le seul à pouvoir lire ses fichiers. En réalité, les mots de passe stockés sur les serveurs… donc, potentiellement, d’autres personnes comme les employés ont aussi accès aux données…
Bref, on a un beau mensonge commercial pour essayer de bien placer sa solution à moindre frais (de développement)…
Et pourtant, aujourd’hui, la cryptographie est un domaine connu et largement documenté…
« Ayez confiaannnce… »
Si la forme du stockage des objets numériques ne fait plus aujourd’hui de doute, il manque maintenant une autre pièce importante à l’édifice.
Stocker, c’est bien, partager c’est mieux… et plus encore si ce partage est parfaitement contrôlé.