Maintenant, la librairie et le programme par défaut sont chargés par le bootstrap depuis des objets. On revient à la situation d’origine avant le passage à la programmation orienté objet.
Auteur/autrice : webmaster
Avancement
La remise en place des fonctions de la librairie nebule en php orienté objet ainsi que la ré-écriture du bootstrap pour en profiter reprend pleinement.
La résolution du graphe des mises à jours des objets, c’est à dire le suivi des liens de mises à jours, est fonctionnelle. On peut donc maintenant rechercher la dernière version de la librairie ainsi que la dernière version du programme à charger par défaut.
La librairie ayant le minimum fonctionnel pour le bootstrap, elle y a été intégralement copiée. Plus tard, elle sera allégée des fonctions non utilisées. La librairie étant plus modulable, les modules non nécessaires au bootstrap ne seront simplement pas intégrés.
La cible : faire charger la librairie par le bootstrap et le programme par défaut.
Le programme sylabe est fonctionnel sur la librairie actuelle moyennant la conservation des fonctions procédurales. Ces anciennes fonctions seront progressivement transformées pour utiliser les nouvelles fonctions en programmation orienté objet… et/ou supprimées dès que sylabe aura été mis lui aussi à jour. En attendant, il intègre en bas de page les nouveaux compteurs du nouveau bootstrap.
Localisation des objets
La possibilité de localiser un objet ou juste une entité me travaille depuis un moment. Même si cela n’a pas d’application aujourd’hui, il est plus logique de faire remonter la possibilité de localisation au niveau de l’objet. Ainsi, si il sera toujours possible de localiser une entité, on peut imaginer soit localiser un objet soit aussi s’en servir pour demander à un robot d’héberger cet objet.
Ainsi, l’objet méta contenant la propriété ‘nebule/objet/entite/localisation‘ est doublé de ‘nebule/objet/localisation‘ pour l’instant et disparaîtra à terme. CF wiki.nebule.org – Documentation – nebule v1.2 – Objets à usage réservé
Les propriétés ‘nebule/objet/entite/webaccess‘ et ‘nebule/objet/entite/webaccess/firstofall‘ sont périmées et dès maintenant supprimées.
Les différentes propriétés ‘nebule/objet/entite/suivi/...‘ sont en sursit.
Changement d’identifiant d’entité
On avait déjà vu qu’une entité pouvait être amenée à changer d’identifiant, donc en fait de clé publique et de clé privée. On avait vu que renouveler son entité n’est pas un problème facile à résoudre de façon satisfaisante, c’est à dire vraiment sécurisée et facile pour l’utilisateur.
Du point de vue interface, la nouvelle entité change aussi de couleur propre. Donc on ne peut pas demander à l’utilisateur par ailleurs de se fier à cette couleur propre des objets puisqu’elle va changer complètement à chaque mise à jour de ceux-ci. C’est ici que se fait sentir le besoin d’une référence d’objet stable dans le temps quelque soit les mises à jours, mais cette référence est par nature source de conflit d’une entité à l’autre et surtout elle est impossible à sécuriser.
Le problème est plus simple si l’entité est dépendante d’une autre entité, d’une entité maitresse. A condition que cette entité maitresse soit publiquement déclarée, comme le puppetmaster, il est possible de vérifier de façon sûr qu’une entité à changé de clé privée. CF Entités multiples, gestion, relations et anonymat
Par contre, une entité autonome ou assimilée ne peut pas se reposer sur une entité supérieure. Il faut prévoir un mécanisme qui permette à l’utilisateur d’une entité lambda de valider automatiquement ou manuellement la mise à jour d’une autre entité. Cela ne veut pas dire que l’autre entité ne changera pas d’identifiant, mais que cet identifiant ne sera pas reconnu tant que l’entité lambda n’aura pas validé (pour elle) son changement.
Pour le changement d’une entité qui potentiellement remet gravement en question la sureté de fonctionnement, une acceptation inconditionnelle de la mise à jour serait catastrophique. Il peut être utile dans ce cas particulier de générer un lien d’annulation de l’opération, mais un lien qui n’est pas actif, c’est à dire qui n’est pas diffusé. Ce lien de type x, serait affiché à l’utilisateur et serait donc valide mais pas pris en compte parce que non diffusé avec les autre liens.
Si on prend le cas spécifique de puppetmaster, cette entité valide des entités esclaves ayant des rôles près-définis. On retrouve notamment l’entité bachue qui diffuse les mises à jours logiciels liées au projet nebule. La compromission d’une telle entité poserait de graves problèmes de sécurité pour toutes les entités. Sa mise à jour vers une nouvelle entité serait dans ce cas obligatoire.
Mais ce problème pourrait être plus restreint dans la mesure où une fausse entité bachue serait générée et diffusée à des entités tierces. Si, par un autre moyen, on arrive à convaincre les entités tierces à l’utiliser en place de la vraie entité bachue, ces entités seront à considérer comme compromises. Le lien d’annulation serait alors le seul moyen pour ces entités de pouvoir revenir en arrière, faisant immédiatement un bond en arrière en terme de versions de logiciels, revenant à une version validée par l’entité bachue légitime.
Sauf que cela ne marche que si l’on peut enregistrer le lien de suppression hors du système nébulisé ou hors d’atteinte. Ce qui sera une vraie difficulté sur des systèmes entièrement nébulisés. Aujourd’hui, avec les systèmes d’informations actuels, on s’en sort en régénérant une nouvelle identité à l’utilisateur ou en nettoyant son compte. Peut-être faudra-t-il dans un premier temps garder ce fonctionnement avant d’aller vers quelque chose de plus ouvert…
Affichage de la couleur d’un objet
Une des orientations actuelles dans les interfaces graphiques centrées sur nebule, c’est de représenter les objets par leurs identifiants et pour chacun par des carrés de couleur spécifiques. Chaque objet a sa couleur propre calculée par rapport aux 6 premiers digits de son identifiant.
Mais du point de vue de l’interface visuelle, si la représentation de l’identifiant équivoque d’un objet est indispensable, sa place encombrante n’est ni ergonomique ni pratique ni vraiment sécurisante à elle seule. Garder systématiquement la place pour un nombre hexadécimal de 128 caractères au minimum, fut-il l’objet en cours de consultation, c’est encombrant. L’ergonomie en prend un coups puisque l’on doit grader un grand espace variable pour une information certes importante mais peu pertinante pour l’utilisateur la plupart du temps. Enfin, puisqu’il est illusoire de penser pouvoir mémoriser l’intégralité des identifiants que l’on utilise pour les vérifier, à part quelques cas spécifiques l’affichage des identifiants des objets n’amène pas directement de sécurité pour l’utilisateur. Le problème de mémorisation est le même que pour les mots de passes multiples, passé un certain nombre, très restreint, cela affaiblie la sécurité de l’ensemble.
Il est tentant de remplacer purement et simplement l’affichage de l’identifiant d’un objet juste par son carré de couleur propre. Cela entraînerait l’impossibilité de vérifier immédiatement si l’objet que l’on visualise est le bon. On peut savoir avec la couleur si l’objet est celui que l’on attend. Mais la représentation des couleurs ne dépasse pas 24 bits d’information. C’est à dire qu’en ajouter plus que les 24 bits n’est pas perceptible par l’oeil humain. Ainsi, la couleur est un moyen de tri rapide mais pas un moyen de sécurité.
Le problème de ne pas pouvoir vérifier immédiatement et de façon sûr un objet est déjà un problème en soit mais peut être comblé par l’usage des liens. Par contre, la gestion des entités et notamment la reconnaissances de nouvelles entités uniquement sur leurs couleurs propres est un vrai problème de sécurité. Il est facile de générer une nouvelle entité ayant la même couleur propre. Avec 24 bits à respecter, cela ne présente pas une grande difficulté. L’identification d’une nouvelle entité doit dans tout les cas être parfaitement sécurisée, donc elle doit être basée sur l’intégralité des identifiants.
Il faut donc soit conserver l’affichage de l’identifiant des objets, même partiel(tant qu’il est suffisamment grand). Soit il faut trouver une méthode alternative de représentation simple des objets tout en conservant un espace de valeur correct.
Au moins deux méthodes peuvent être envisagées, liste non exhaustive.
On peut utiliser un petit pictograme de plusieurs couleurs successives calculées à partir de l’identifiant d’un objet. Le prictograme peut disposer d’un espace de valeurs suffisamment grand tout en étant facilement mémorisable.
On peut imaginer qu’une entité spécifique utiliser certaines valeurs choisies au hasard parmi tous les digits des identifiants pour calculer les couleurs propres des objets. Comme il faut 6 digits hexadécimaux pour constituer une couleur, ceux-ci sont choisis non pas au début des identifiants mais à l’intérieur. ce choix doit être aléatoire, secret pour l’entité et non recalculable par une entité tierce. Dans ce cas, la couleur affichée pour un même objet serait différente pour chaque entité qui consulte cet objet.
Nommage d’objets et d’entités
Dans la vraie vie, le nommage des personnes a une forme conventionnelle. Il en est de même de fait pour les fichiers puisqu’ils sont tous gérés de la même façon.
Dans nebule, chacun des objets disposent d’un identifiant unique mais aussi d’un nom, même si ce dernier n’est pas obligatoire. Le nom est cependant nécessaire à l’être humain pour classer et retrouver ses données. Pour les entités, qui sont gérées comme des objets, elles ont aussi un nom mais la forme est un peu différente même si le but est similaire au nom de l’objet.
Dans nebule, tous les objets peuvent avoir ces propriétés :
- nom
- prénom
- surnom
- préfixe
- suffixe
Ces propriétés sont matérialisées par des liens de type l avec comme objets méta, respectivement :
nebule/objet/nomnebule/objet/prenomnebule/objet/surnomnebule/objet/prefixnebule/objet/suffix
Par convention, voici le nommage des objets pour l’affichage :
prénom préfixe/nom.suffixe surnom
Le prénom et le surnom n’ont que peu d’intérêt.
Les entités disposent naturellement des mêmes propriétés, mais leur nommage pour l’affichage est un peu différent.
Par convention, voici le nommage des entités :
préfixe prénom "surnom" nom suffixe
Ici, c’est le suffixe qui a peu d’intérêt.
Une dernière remarque. Bien que certaines propriétés n’aient pas aujourd’hui de grand intérêt pour l’affichage, le fait de le proposer aux utilisateurs les rend automatiquement inamovibles. Il y aura toujours quelqu’un qui leur trouvera une utilité et les utilisera… d’où l’intérêt dès maintenant d’une convention d’affichage.
La documentation est mise à jour en conséquence : wiki.nebule.org – nebule_v1.2 – Objet
Avancement
Afin de tester les nouvelles fonctions avec sylabe, et pour pouvoir aussi reprendre le développement de ce dernier, les anciennes fonctions de la librairie en php procédural sont réinjectées dans la librairie en php orienté objet. Ainsi sylabe fonctionne et les anciennes fonctions procédurales vont pouvoir être progressivement reprogrammées pour faire appel aux nouvelles fonctions orienté objet…
Le code n’est pas encore diffusé puisqu’il est assez ‘sale’. Mais ça viendra…
Mémorisation de liens et accélération des traitements
Par défaut, à chaque chargement d’un objet pour traitement ou pour son affichage, chaque liens sont lus et vérifiés, puis relus et revérifiés. Parce que cette vérification implique des algorithmes cryptographiques de prise d’empreinte et des algorithmes cryptographiques asymétrique (à clés privées), le traitement cumulé de chaque vérifications devient vite une quantité non négligeable. Bref, le temps de calcul se ressent dans le traitement.
Il est possible d’accélérer ce fonctionnement avec la mémorisation des vérifications déjà faites.
Pour commencer, on peut considérer en première approximation que la plus grande partie du temps de traitement est imputable à la cryptographie asymétrique. On considère donc par défaut que les autres traitements sont, temporellement, quantités négligeables. cette approximation est vérifiée en pratique dans sylabe lorsque l’on désactive la vérification des signatures.
Pour des raisons de sécurité, les liens qui ont été vérifiés, et que l’on souhaite mémoriser, doivent être mémorisés en intégralité. Il ne faut pas garder uniquement la signature du lien. Il est préférable de conserver l’intégralité du lien. Tout au plus peut-on supprimer le champs signature. Ces liens pré-vérifiés doivent être conservés en lieu sûr, non modifiable par une autre entité ou un autre processus.
Dans ce cas, la vérification d’un lien va commencer par le parcours des liens déjà vérifiés, puis en dernier recours à vérifier le lien. Au delà d’un certain nombre de liens mémorisés, il est possible que le bénéfice de la mémorisation soit négatif vis-à -vis de la vérification direct des signatures des liens. Il faudra montrer expérimentalement l’ordre de grandeur de la table des liens mémorisés. Qui dit table de mémorisation limité dit aussi gestion de la quantité de liens mémorisés et donc du remplacement de certains liens par d’autres. Ce remplacement peut se faire en boucle, sans calcul, ou au contraire en tenant compte du temps de dernier usage des liens mémorisés. Bref, il y a du travail d’optimisation en perspective.
Comme on l’a vu avec une table de mémorisation limitée, le temps de mémorisation des liens peut être variable. De même, une autre période de rétention peut exister. La table de mémorisation peut n’être valable que pour le temps de chargement d’une page (web). Ou au contraire la table de mémorisation peut être valable le temps de la session, c’est à dire tout le temps ou l’entité est déverrouillée. Dans le cas de navigations sur sylabe, et en étant non-déverrouillée, la mémorisation peut être liée à la session php, et donc expirer avec celle-ci.
Imaginons maintenant un peu le futur. Imaginons que chaque entité, chaque humain dispose de sa clé privée en permanence dans un périphérique, ou plutôt une prothèse. Empactée dans du matériel, la clé privée serait beaucoup mieux protégée. De fait, corrompre la table de mémorisation des liens vérifiés deviendra un moyen plus facile pour modifier le comportement d’une entité. Il doit donc être maintenu la possibilité de fonctionner en mode paranoïaque en vérifiant à chaque utilisation les liens.
Etude du temps
Voici dans le wiki une nouvelle étude sur le temps et sa représentation. Cette étude va permettre de poser les bases de la gestion du temps dans le projet nebule. Cette gestion du temps implique sa, ou plutôt, ses représentations ainsi que les traductions associées. Les représentations du temps affiché peuvent être multiples en fonction de critères culturels, religieux, ou géographiques. Mais elles doivent toutes être traduisibles dans d’autres représentations.
Nous n’étudierons pas ici la mesure du temps. La mesure implique la quantification d’une propriété physique. Nous ne faisons qu’utiliser des mesures de temps déjà quantifiées.
J’en profite pour remercier ici Mr Jean-Daniel Morerod. Il me permet de mettre en ligne une copie sur le wiki de son article co-écrit avec Mr Justin Favrod : Histoire du temps : l’origine du calendrier.
Avancement
La ré-implémentation de la librairie en php orienté objet avance.
Un gros point de blocage vient de sauter. Il s’agissait d’implémenter la résolution d’un graphe de liens de mises à jours. L’implémentation précédente fonctionnait bien mais nécessitait une sous fonction qui s’appelait elle-même au fur et à mesure du parcours des liens u. Ici, il fallait forcément implémenter une fonction de recherche des mises à jours sur un niveau pour un objet. Mais en contre-partie, et moyennant un fonctionnement plus complexe, il a été possible de ne plus utiliser la sous-fonction auto-appelée…
Bref, c’est plus complexe à comprendre mais c’est aussi plus propre :-)
Voici le genre de chemin suivi pour la résolution du graphe de mise à jour d’un objet. Ici le cheminement est linéaire entre les objets intermédiaires, il devra être éprouvé sur un cheminement non linéaire (avec des objets manquants).
On part de l’objet 47c1b111409c3a9ccb193b19c481b38715f9fc96da706d98c070ef9019890cb9 et on arrive à 672bad4d2c4bd4a5def227671a0eb22844dbb116d59d4cb948ecbaa4f6b0b549 (sur une base de liens plus réduite):
2013-12-06_u_47c1b111409c3a9ccb193b19c481b38715f9fc96da706d98c070ef9019890cb9_5376cfdb8b8d3e1c9c4832bb9d8cab0ba076bbf2d28ae53c8680088641d2aa85 2013-12-07_u_5376cfdb8b8d3e1c9c4832bb9d8cab0ba076bbf2d28ae53c8680088641d2aa85_e2e0fec866c726f3b284575435a81080f279e4afb46a7ba07edc39105f061a7f 2013-12-10_u_e2e0fec866c726f3b284575435a81080f279e4afb46a7ba07edc39105f061a7f_9864740a3679164edfc130ba64658926470227e6a94056ce200a1157f729a940 2013-12-11_u_9864740a3679164edfc130ba64658926470227e6a94056ce200a1157f729a940_aafc618df11870db1c833a6f0e31e8c4246645001b515040ee7d84cde135e617 2013-12-12_u_aafc618df11870db1c833a6f0e31e8c4246645001b515040ee7d84cde135e617_1e45b26a70a8f19e3515d981100fc7a135b6b6e480bb170d41d2033120a02fec 2013-12-13_u_1e45b26a70a8f19e3515d981100fc7a135b6b6e480bb170d41d2033120a02fec_0a2d68d69eca2bd3b83ea0306bc868c4ee684e8eb1665e9215263ea05a54c426 2013-12-24_u_0a2d68d69eca2bd3b83ea0306bc868c4ee684e8eb1665e9215263ea05a54c426_284ea4d9be9b206d73297bda696c77ef3389c47330e5b1d4c13dcf3ab3c5d20d 2013-12-26_u_284ea4d9be9b206d73297bda696c77ef3389c47330e5b1d4c13dcf3ab3c5d20d_182b6e830ba6b21411695e9f99fddfddd12c0bee61fce41368c98e0c1254dab5 2014-01-02_u_182b6e830ba6b21411695e9f99fddfddd12c0bee61fce41368c98e0c1254dab5_e304bf8534de8b6fba8a88bcbbcd520439527a8719579c1db2d3465465e463a9 2014-01-10_u_e304bf8534de8b6fba8a88bcbbcd520439527a8719579c1db2d3465465e463a9_ab46a8ed5c21a2d8ff9103088a8cdc07ea167eb577b3cc4ac0ec29b4388c4b0c 2014-01-13_u_ab46a8ed5c21a2d8ff9103088a8cdc07ea167eb577b3cc4ac0ec29b4388c4b0c_79ddbdd834c136e4616b71372de11d786b4730ea040bd732b1d91e17b10398b0 2014-01-16_u_79ddbdd834c136e4616b71372de11d786b4730ea040bd732b1d91e17b10398b0_d6d226f89a247ef361ae1c0b0eb1c5383ea2ee7c1ee607255f84727b7da2c962 2014-01-17_u_d6d226f89a247ef361ae1c0b0eb1c5383ea2ee7c1ee607255f84727b7da2c962_59b802549352603e2cc9d386788bbfe0336045cc841b96bdb707f87f4d9d0bbd 2014-01-18_u_59b802549352603e2cc9d386788bbfe0336045cc841b96bdb707f87f4d9d0bbd_0131a0b7b758d24be4ecc6701fc942c8c73044f3fa85aa2e82fe42b5cfcf05d9 2014-01-22_u_0131a0b7b758d24be4ecc6701fc942c8c73044f3fa85aa2e82fe42b5cfcf05d9_dd27f522db318f7fcf54852af861e656b184bd178c9718c7186efcedda49dba2 2014-01-23_u_dd27f522db318f7fcf54852af861e656b184bd178c9718c7186efcedda49dba2_72ebbabbf4687106a70b5bba7f9c10ab096febd649f306660411f2cc6215981e 2014-01-24_u_72ebbabbf4687106a70b5bba7f9c10ab096febd649f306660411f2cc6215981e_b364e1bf7181fa508032d5d26562350be6aadbb14949137e8d442bdc1912493b 2014-01-29_u_b364e1bf7181fa508032d5d26562350be6aadbb14949137e8d442bdc1912493b_cc1ec77ea4d137b7785c2de9dab0d818420f520f3502788aec56e1ca3cb081ac 2014-01-30_u_cc1ec77ea4d137b7785c2de9dab0d818420f520f3502788aec56e1ca3cb081ac_c971f678bbfeba808c0f0b4f23f6d3f3bed21c098437ecfe54e0c46891696462 2014-01-31_u_c971f678bbfeba808c0f0b4f23f6d3f3bed21c098437ecfe54e0c46891696462_27ec39235f7f49f1a862ac303e54125cc2941455b832000957583130e08896eb 2014-02-02_u_27ec39235f7f49f1a862ac303e54125cc2941455b832000957583130e08896eb_c92173177ed98cfbb651a76670b3e508834bbb217ac91b285c8ab20994f5b249 2014-02-03_u_c92173177ed98cfbb651a76670b3e508834bbb217ac91b285c8ab20994f5b249_02ef13f3824b6412cbd38b9c33266a601b18a8812b84aff3fffb7647723b1883 2014-02-05_u_02ef13f3824b6412cbd38b9c33266a601b18a8812b84aff3fffb7647723b1883_60de6086e63a85db4a39ca06f1bccb966eaa3cb6d805889210a6cc63c5c59757 2014-02-06_u_60de6086e63a85db4a39ca06f1bccb966eaa3cb6d805889210a6cc63c5c59757_8334ed17bfe94db33690049ecae724b58e420478d62a902503bb95ab17e013ba 2014-02-07_u_8334ed17bfe94db33690049ecae724b58e420478d62a902503bb95ab17e013ba_a6e76573b865ca90fb92b247c724474456db38023b6b9716b45ef41c6742e164 2014-02-08_u_a6e76573b865ca90fb92b247c724474456db38023b6b9716b45ef41c6742e164_b8fb4e2a4fa515cc8ce6d130ab7cfcfa7138150d3117357514bfb5d868a726c4 2014-02-09_u_b8fb4e2a4fa515cc8ce6d130ab7cfcfa7138150d3117357514bfb5d868a726c4_b338bd787b97e6cd85ce9965b00d17a86d51255b87c8686d0444b6a87ea7f034 2014-02-10_u_b338bd787b97e6cd85ce9965b00d17a86d51255b87c8686d0444b6a87ea7f034_d4115805c826483a0a5f6988be4fcc4bac8b04d300cbb3c8f0244194777931f9 2014-02-12_u_d4115805c826483a0a5f6988be4fcc4bac8b04d300cbb3c8f0244194777931f9_221ec95e1046265b03dc8800a7efed44df5e49b6db3b9f51048370009022698d 2014-02-13_u_221ec95e1046265b03dc8800a7efed44df5e49b6db3b9f51048370009022698d_b80e64fc316768932fab063b35d47e3651eed66be7ca8756d2cb0bc82afbd683 2014-02-16_u_b80e64fc316768932fab063b35d47e3651eed66be7ca8756d2cb0bc82afbd683_76e3f1f5d64a221bf1a28964ae74f9752af3b26763b46523ea3b5e6a2a20511a 2014-02-17_u_76e3f1f5d64a221bf1a28964ae74f9752af3b26763b46523ea3b5e6a2a20511a_d1fd4dba3ec0ec7fda4898a16eac6593d10e80cb575511fd9cbe85ec214e487f 2014-02-18_u_d1fd4dba3ec0ec7fda4898a16eac6593d10e80cb575511fd9cbe85ec214e487f_fbf7bcc5c27981b8953e2a8630f572774f6c16684ac8459bb240aeaca8bd8ff7 2014-02-20_u_fbf7bcc5c27981b8953e2a8630f572774f6c16684ac8459bb240aeaca8bd8ff7_8badc8ba4a855acbbe58de48e5ac3fa4aeb3c3c69858401778adf771ed19be15 2014-02-21_u_8badc8ba4a855acbbe58de48e5ac3fa4aeb3c3c69858401778adf771ed19be15_f05b4ac2d53b7287af3f15c3ab2e7da13fc3a80b37272cbbcfb400d287568f63 2014-02-22_u_f05b4ac2d53b7287af3f15c3ab2e7da13fc3a80b37272cbbcfb400d287568f63_761625eb463d1e3930b80cf88d43157d778d10a23f3d0cba463c552322492b72 2014-02-24_u_761625eb463d1e3930b80cf88d43157d778d10a23f3d0cba463c552322492b72_941752dc44b4a272bd7828724f7f3bd554fa1f3acca4dcb298f0ecf5428ecfbf 2014-02-25_u_941752dc44b4a272bd7828724f7f3bd554fa1f3acca4dcb298f0ecf5428ecfbf_a3d7fcf4f1c88ce5350f065e16ce770cc6d6de6334e7fb6dd8403398c86ea1e5 2014-02-26_u_a3d7fcf4f1c88ce5350f065e16ce770cc6d6de6334e7fb6dd8403398c86ea1e5_1f3e1cec5ab724a701d7665f13003dc50765c3a066227d322d64804651de0ade 2014-02-27_u_1f3e1cec5ab724a701d7665f13003dc50765c3a066227d322d64804651de0ade_5154aa3a5ea8956db2279dbaa2d3944b5a87218202e838c2a4cfc27da172ed6e 2014-03-04_u_5154aa3a5ea8956db2279dbaa2d3944b5a87218202e838c2a4cfc27da172ed6e_0a65036105b001b926d1d0336aa4de5fde1d8a476f325f9832e524d914e7e465 2014-03-26_u_0a65036105b001b926d1d0336aa4de5fde1d8a476f325f9832e524d914e7e465_5ac97a3a3c7c310b5afe24c210874c1b2ae69a80274755117cb7b8bb3b9299be 2014-03-28_u_5ac97a3a3c7c310b5afe24c210874c1b2ae69a80274755117cb7b8bb3b9299be_17bf49d31d9a2ab2d0d051ed1bb4c6a0acdfcad6da199fc86ebf47d8be284f40 2014-03-29_u_17bf49d31d9a2ab2d0d051ed1bb4c6a0acdfcad6da199fc86ebf47d8be284f40_9559ba4972cd3a4ada0d055101efdca7d6c0f942279c6bd05f23b2d0b118c111 2014-04-01_u_9559ba4972cd3a4ada0d055101efdca7d6c0f942279c6bd05f23b2d0b118c111_a6968f3bb36ea04264f6e2314c661af3f4acda829a4515b73b701aea244b1582 2014-04-02_u_a6968f3bb36ea04264f6e2314c661af3f4acda829a4515b73b701aea244b1582_f74debe6a24400c6dbbb4388eefac050d204b5073f643a3302c24fc15e7544c6 2014-04-03_u_f74debe6a24400c6dbbb4388eefac050d204b5073f643a3302c24fc15e7544c6_f6d07dd9f4e946bab71f1084d027f6b9cc16d7161e62cc4562e0bd94cce502d7 2014-04-04_u_f6d07dd9f4e946bab71f1084d027f6b9cc16d7161e62cc4562e0bd94cce502d7_c8dbec0f85e19c313317f552e7acfaa2a23097150e592da400643d4c18884b94 2014-04-08_u_c8dbec0f85e19c313317f552e7acfaa2a23097150e592da400643d4c18884b94_28ae03264ae8505767aa5e3a3cbaf7d0a8a96c92236de5a10c14d694c498438a 2014-04-09_u_28ae03264ae8505767aa5e3a3cbaf7d0a8a96c92236de5a10c14d694c498438a_33ae1c2aa592fb7ac7f95f03abfd5a6b46d4da48579a3153258890298336a01a 2014-04-10_u_33ae1c2aa592fb7ac7f95f03abfd5a6b46d4da48579a3153258890298336a01a_648f35156e67da0bdd9477020129c42e9ed07ac4f67e784f0f0cd931b1b4419c 2014-04-11_u_648f35156e67da0bdd9477020129c42e9ed07ac4f67e784f0f0cd931b1b4419c_907e5d86dec334e80a5e81d4e0b842bbeb0b491c7bba38699da25aa880ac49b8 2014-04-12_u_907e5d86dec334e80a5e81d4e0b842bbeb0b491c7bba38699da25aa880ac49b8_672bad4d2c4bd4a5def227671a0eb22844dbb116d59d4cb948ecbaa4f6b0b549
Entités multiples, gestion, relations et anonymat
On peut raisonnablement penser que chaque personne, sauf problème, a une personnalité unique. Et donc qu’une personne a un comportement unique et un réseau sociale unique.
Mais la réalité n’est malheureusement pas aussi simple.
Ne prenons que l’exemple de l’individu employé dans une société. Cet environnement est à considéré comme différent de l’environnement de vie normal, c’est à dire chez soi, dans la vie privée. Au travail, nous avons des « amis imposés par l’employeur » qui forment un réseau social souvent fortement découplé du réseau social privé. Nous avons aussi des attitudes différentes, en phase avec les attitudes que l’entreprise attend de nous. Nous sommes en short à la maison, avachi devant la télévision alors que l’on est en costume 3 pièces au travail, bien assit devant son ordinateur. Les réseaux sociaux ainsi que les échanges avec les autres individus évoluent avec l’environnement dans lequel on se situe. Chacun de nous est unique mais chacun de nous adopte une pseudo-identité variable dans l’espace et le temps. Enfin, on mélange rarement les informations de ces différentes pseudo-identités. On parle rarement en détail de sa journée de travail avec des amis le weekend autour du barbecue.
Sur un réseau social numérique, comme Facebook ou Google+, imposer une identité unique est donc une vision réductrice de l’individu humain. En cherchant à n’avoir que des identités réelles des individus, on se coupe de toutes leurs identités annexes. Et une relation de travail fait typiquement d’une identité annexe.
On ne s’attardera pas ici plus longtemps sur la justification des entités multiples mais plutôt sur la technique et les possibilités que cela ouvre.
Les premières expériences avec les identités dans nebule montrent qu’un individu peut, bien évidemment, avoir plusieurs entités différentes. Chaque entité peut avoir une « vie » propre, c’est à dire un réseau social à part. Une entité peut mettre en place des entités esclaves, elles sont dans ce cas parfaitement autonomes. Elles restent autonomes même si elles sont tenues par une entité maitresse.
L’entité puppetmaster est le premier exemple d’entité maitresse. Il y a dans ce cas une idée de validation forte. On peut avoir d’autres types de relations entre entité maitresse et entités esclaves. On peut avoir des cas où la validation serait au contraire réduite voir dissimulée, dans les cas où l’anonymat est recherché.
Vis-à -vis de l’interface homme-machine, la notion même d’entités multiples n’est pas triviale. Sur nos systèmes d’information actuels, sur nos ordinateurs, téléphones, tablettes, etc… il est courant de disposer de plusieurs comptes utilisateurs. Mais on ne peut utiliser simultanément qu’un seul compte à la fois. Tout au plus peut-on changer temporairement d’identité (élévation de privilèges par exemple). Chaque action se fait sous une et une seule identité.
Si on utilise plusieurs comptes de messagerie ou comptes de réseaux sociaux numériques, il faut quitter un compte pour pouvoir accéder à un autre.
Dans une interface exploitant nebule, il est cependant possible de travailler de la même façon ou différemment.
On peut disposer de plusieurs entités et se connecter à une et une seule entité à un instant donné.
On peut aussi se connecter à une entité maitresse et basculer, immédiatement après, vers une des entités esclaves. C’est déjà fonctionnel dans sylabe. Il est même possible de revenir facilement vers l’entité maitresse pour éventuellement repartir sur une autre entité esclave. Ainsi on évolue dans des environnements isolés via des entités autonomes. De plus, la relation entre l’entité maitresse et les entités esclaves peut être masqué (offusqué).
Mais il est possible d’aller plus loin. On peut tout à fait imaginer exploiter simultanément plusieurs entités. Cela permet d’avoir une vue synthétique de plusieurs réseaux sociaux ainsi que des échanges associés. Le cloisonnement dans ce cas est invisible pour la consultation tout en restant potentiellement très fort entre chaque entités. En pratique, on pourrait voir les activités de tous les « amis » de toutes les entités esclaves que l’on contrôle même si chaque entité esclave n’a strictement aucun rapport ou aucun lien avec les autres entités esclaves. Il faut par contre définir une entité avec laquelle on agit par défaut, au risque de casser le cloisonnement des entités par des liens inappropriés. On peut même imaginer que des interactions avec un réseau social particulier se fassent avec l’entité esclave attaché au réseau en question, on conserve ainsi le cloisonnement des entités mais pas celui de l’information. En somme, c’est un peu ce que l’on fait déjà avec un logiciel client messagerie et plusieurs comptes de messagerie…
Facebook et l’anonymat
Les positions bougent aussi du côté de Facebook. Dans la suite de l’article précédent sur Google+ et l’anonymat, c’est au tour du premier réseau social de faire des concessions sur la possibilité de créer des comptes anonymes… dans une certaine mesure.
Depuis le 1er octobre, il est possible d’utiliser un pseudonyme. Tout n’est pas encore permit mais l’avancée est de taille alors que la vie privée n’était clairement pas la priorité de Facebook. Et l’anonymat était même malvenu jusque là pour inciter les internautes à avoir de vraies relations d’amitié. Il était aussi quand même plus intéressant pour les publicitaires de disposer d’informations fiables sur les utilisateurs…
Depuis peu, une nouvelle messagerie est en cours d’élaboration, par Facebook, pour permettre des échanges volontairement anonymes. Un vrai retournement… ou une opportunité commerciale de plus…
CF :
– http://www.lemonde.fr/economie/article/2014/10/02/les-pseudonymes-finalement-autorises-sur-facebook_4498801_3234.html
– http://www.lemonde.fr/pixels/article/2014/10/08/facebook-va-lancer-une-application-permettant-des-echanges-anonymes_4502637_4408996.html
Interface par défaut de serveurs
Une nouvelle interface est terminée, elle concerne les serveurs en php. Cette interface s’appelle nServ et ressemble à ça :
Elle peut être simplement définit comme étant l’application par défaut en utilisant le bootstrap classique. Elle peut aussi, si on n’implémente pas php, et donc pas de bootstrap, être présente comme fichier par défaut index.html avec les informations écrites directement dans la page et non générées automatiquement. Dans ces informations, on retrouve le nom public de l’entité, son identifiant et quelques informations sur nServ et sa licence.
A noter que le nom est ici celui de mon entité, mais se sera à terme normalement celui d’une entité de serveur…
Transfert de liens et de confiance
Les réseaux fragmentés posent des problèmes plus importants que le maintient de la cohérence du système d’horodatage. CF Gestion temporelle partielle.
Certains protocoles de sécurisation des échanges deviennent bancales sans synchronisation de temps. Mais il y a plus grave. La cohérence du temps entre plusieurs machines peut être négligé sur une courte période, les horloges ne vont pas dériver exagérément et il y a peu de change que des certificats expirent. Par contre, il devient difficile de transmettre de nouveaux contacts avec un grand niveau de confiance. les relations de confiance sont souvent dépendantes de services centralisés, services qui ne sont plus forcément joignables. Ces services ont le rôle d’annuaires globaux. Il faut dans ce cas faire confiance aux seuls intermédiaires que l’on a sous la main, et que l’on connaît (au moins dans nebule). On doit utiliser des entités comme des annuaires locaux.
Dans ce cas, il est peut-être utile de voir si la définition d’un nouveau type de lien ne pourrait pas répondre à ce besoin. Ce serait un lien signé par une entité que l’on connaît et qui transmettrait un lien d’une autre entité, inconnue. Un lien serait encapsulé dans un autre de la même façon que pour un lien offusqué. La validité et la pondération du lien de l’entité inconnue seraient les mêmes que si le lien venait de l’entité connue. Ce serait une forme de relais de liens.
Ce type de lien aura peut-être aussi une utilisé pour les annuaires d’entités. Cela pourrait faciliter la mise en relation entre deux entités qui ne se connaissent pas.
Mais, c’est aussi un risque qui faut analyser. On commence dans ce cas à prendre en compte des liens d’une entité que l’on ne connaît pas et que l’on ne peut directement vérifier. Il faut voir ça comme si l’entité qui fait le relais des liens s’appropriait elle-même le lien. Cette entité peut diffuse des liens invalides, c’est à dire dont la signature est invalide, sans que l’on puisse le vérifier. L’affiche de ces liens ou leur interprétation doit être peut-être adapté pour montrer cette particularité…
Marque de temps
Il est maintenant clair qu’il faut aller plus loin que la norme ISO8601. Il faut que le code soit capable d’interpréter différents calendriers connus ou pas, par extension. Dans ces calendriers pourront prendre place une référence de temps en temps long tel que le calendrier Maya.
CF : Gestion temporelle partielle, Horodatage, ISO 8601, suite et Marque de temps.
Gestion temporelle partielle
Il y a deux façons de gérer le temps et deux façons pour le prendre en compte.
C’est la suite des articles Horodatage, ISO 8601, suite et Marque de temps.
La référence de temps, ou pas
On peut gérer le temps comme étant un prérequis commun à tous les acteurs. Dans ce cas, toutes les machines doivent synchroniser leurs horloges internes sur une source commune. Tout le monde travaille avec la même heure, le même espace temps et la même référence. Ici on ne tient pas compte du fuseau horaire qui est un bricolage de décalage non pas temporel mais sur l’affichage uniquement. Aujourd’hui, l’orientation de tous les systèmes d’informations, c’est la synchronisation globale, c’est à dire la même partout sur la planète.
On pourrait aussi simplement considérer que chaque machine, chaque utilisateur, a un espace temps qui lui est propre. Pas de synchronisations à faire mais se pose alors l’interprétation d’une date donnée par une autre machine. Il faut prévoir un mécanisme de correction du temps des autres machines, par rapport à une référence. On retrouve cette référence commune mais elle peut dans certains cas être soi-même, c’est à dire je suis à la bonne heure et je compense l’heure des autres. En cas d’absence de référence externe, il faut retenir le décalage de chacune des machines avec lesquelles on communique.
Avoir une référence commune implique une communication régulière avec cette référence. Il faut donc une connexion réseau, même partielle. Plus la précision attendue dans la synchronisation est forte, plus les moyens tant en réseau qu’en relais doivent être importants, rapides et fiables. Sur des réseaux isolés ou fortement fragmentés, la synchronisation du temps devient illusoire. Et cela peut arriver partout sur la planète : catastrophe naturelle, guerre, dictature, repli sur elles-même des nations, etc…
Le problème sur la référence de temps n’est pas que théorique. Ce ne serait pas « juste un problème d’affichage ». Beaucoup de protocoles de sécurisation s’appuient aujourd’hui sur le temps et exigent un horodatage assez précis. Lorsque l’on se connecte au site web de sa banque, lorsque l’on renvoie un message signé, lorsque l’on se connecte à un réseau d’entreprise, les jetons de session et autres certificats électroniques ont une durée de vie limitée ou une date d’expiration. Tous ces services impliquent d’avoir un réseau pour fonctionner et peuvent délivrer une référence de temps en même temps que ces services. Par contre, des documents comme les passeports sont aussi émis avec une date d’expiration et il serait difficile de vérifier leur validité sans une référence de temps commune.
Le système de gestion du temps dans nebule est encore aujourd’hui basé sur l’horloge interne de la machine qui exploite les liens. Il utilisera aussi l’entité kronos comme référence. Mais il est prévu de calculer et mémoriser les décalages de temps entre machines. Cette capacité à mémoriser les variations de temps rend l’ensemble plus résilient en cas de catastrophe ou tout simplement de fragmentation volontaire des réseaux. A faire…
Sur un réseau maillé comme sur Internet, la structure globale ressemble à un fractal dans lequel on peut zoomer et retrouver les mêmes formes de connexions entre nÅ“uds de réseau. Un réseau Internet fragmenté serait sûrement toujours maillé et toujours interconnecté, mais la structure globale ressemblerait plutôt à une nébuleuse, c’est à dire sans structure marquée. Dans ce deuxième cas, les synchronisations de temps seraient souvent conflictuelles.
Le postulat que l’on peut simplement synchroniser tout le monde sur une seule et unique référence de temps est une facilité de notre époque. Mais c’est une facilité qui n’est ni évidente ni définitivement acquise.
Prise en compte des événements futurs, ou pas
Avec synchronisation du temps entre les machines ou pas, il peut arriver d’une marque de temps soit dans le futur ou interprétée comme telle. Que fait-on dans ce cas ? Est-ce une erreur de l’émetteur ? Est-ce une erreur de synchronisation ? Est-ce une erreur de zone de temps ? Est-ce un acte malveillant ?
Et c’est pareil pour une date du passé qui ne correspond manifestement pas à l’ère informatique. Est-ce une erreur de référence de temps ?
On peut tenir compte d’une marque de temps problématique et l’interpréter telle quelle vis-à -vis des autres date. Dans le cas d’une suppression de lien marqué dans le futur, cette suppression est valable. Mais, parce qu’elle est dans un futur un peu lointain, il va devenir impossible de réhabiliter ce lien avant cette date puisque sa suppression sera toujours valide temporellement. Il faudrait un nouveau lien plus loin dans le futur qui, lui, empêcherait la suppression avant cette nouvelle date dans le futur… On ne s’en sort pas.
On peut ne pas tenir compte d’une marque de temps invalide et l’écarter du traitement comme étant incohérente. Dans ce cas un lien de suppression dans le futur ne serait plus utilisé avant que notre espace temps ne soit arrivé effectivement à cette date.
Mais dans ce cas la synchronisation de temps ou l’utilisation d’une référence de temps a beaucoup plus d’importance puisque des dates du calendrier arabe, hébraïque, indien, chinois ou copte n’ont pas la même signification. Des événements interprétés comme étant dans le futur seront automatiquement ignorés alors qu’ils sont peut-être valides.
La non prise en compte de liens avec une date dans le futur semble la meilleur solution, mais elle n’est pas encore implémentée dans nebule. A faire…
L’implémentation doit aussi permettre de gérer sereinement les décalages, prévisibles, du temps entre différentes machines même si elles ont la même référence de temps. En dessous de la seconde, une synchronisation globale est illusoire. Avec une connexion à Internet intermittente, une précision de l’ordre de la minute est plausible. Il faut donc prévoir un paramètre afin de définir le décalage maximal de temps que l’on accepte pour des liens dans le futur.
L’utilisation de la norme ISO8601 est indispensable mais pas suffisante. Tous les calendriers n’utilisent pas cette forme et bien sûr n’ont pas la même référence de temps. De plus, si il permet une grande précision, il ne permet pas de manipuler le temps sur ce que l’on appelle le temps long. Il serait intéressant de pouvoir manipuler d’autres calendriers, peut-être avec un préfixe spécifique.
Lien juste à temps
Les liens de nebule n’ont pas vocation à permettre un traitement complexe des données, juste à permettre leur transmission et faciliter le traitement.
Manipuler des données avec des échéances n’est possible qu’en associant un objet contenant une date avec un objet méta spécifique. Le traitement à échéance est réalisé par le programme qui interprète cette forme de lien. Il est facile de réaliser au niveau des liens d’une prise en compte « à retardement » d’un lien. Le modèle pourrait être l’encapsulation d’un lien dans un autre lien d’un type particulier, sur le modèle du lien offusqué. Au lien d’une clé de chiffrement, ce pourrait être une date de prise en compte.
Ce nouveau type de lien est de fait en concurrence avec un lien avec une date dans le futur. Mais cela présenterait quand même quelques avantages. Le premier, c’est que la date pourrait être aussi une période de prise en compte. Mais surtout, là où un lien dans le futur pourrait être supprimé parce que considéré invalide, un lien dédié à cet usage serait beaucoup plus légitime.
Cette idée est encore à réfléchir…
Gestion des modules – IO et gros objets
Suite de l’article Gestion des modules.
L’exportation du traitement des IO dans des modules entraîne un autre problème avec les gros objets.
Les gros objets peuvent être visualisés dans le navigateur quoi qu’il arrive puisque la lecture du contenu d’un objet est faite par le navigateur et ce contenu est transmis sans traitement par le serveur web. Ce quelque soit la taille de l’objet.
Par contre, si un objet nécessite un traitement, comme le déchiffrement, alors cela ne marche plus de la même façon.
Le traitement d’un objet nécessite qu’il soit placé en mémoire de l’instance PHP en cours, avec toutes les restrictions et limites que l’on va rencontrer. Il n’est pas possible de travailler facilement comme on le ferait sur bash avec une série de ‘pipes’.
Ce problème va aussi se poser lors de la synchronisation d’un objet sur une serveur web externe, via le module IO HTTP. Avant de pouvoir l’écrire localement, via le module IO FileSystem par exemple, il devra tenir en mémoire.
Il est peut-être possible, dans le das d’échanges entre IO, de mettre en place des copies progressives d’objets pour soulager la mémoire. A voir…
Pour le déchiffrement et l’affichage, il est possible de créer une fonction spécifique. Pour le chiffrement, il va falloir travailler par blocs.
IO HTTP et performances dans PHP
Pour les besoins du module des IO sur HTTP, j’ai réalisé quelques tests afin de déterminer la meilleur méthode pour vérifier la présence d’un dossier ou d’un fichier sur un serveur web via HTTP.
La méthode la plus simple consiste à appeler l’URL de ce que l’on veut avec l’instruction file_get_contents.
C’est très simple mais très lent puisque tout le contenu est téléchargé alors que l’on ne souhaite que l’entête de la réponse du serveur. En fait, on a juste besoin de la première ligne de la réponse pour connaître le code de réponse du serveur, 200 si un fichier est disponible. 404 si le fichier n’existe pas. 403 si le fichier n’est pas accessible pour cause de restriction.
A noter que cette instruction et d’autres comme fopen nécessitent d’autoriser explicitement l’ouverture des URL avec allow_url_fopen=On et allow_url_include=On. Ces options sont nécessaires au bon fonctionnement du bootstrap, cela n’introduit donc pas de configuration supplémentaire.
La seconde méthode consiste à demander l’entête (header) via l’instruction PHP correspondante, get_headers.
Sauf que ce n’est pas mieux puisque le contenu est malgré tout téléchargé même si au final on n’extrait que l’entête.
Une autre méthode consiste à utiliser la librairie CURL dans PHP. Cette librairie est spécialisée dans les manipulations des URL, mais cela oblige à l’installer, ce qui n’est pas forcément la meilleur solution.
Par contre, en terme de performance, c’est d’un autre niveau. On peut raisonnablement savoir si un gros fichier est présent sur le serveur sans avoir de temps de latence démesuré. Au moins pour ces performances, cela peut valoir le coût d’installer cette librairie.
Enfin, une dernière solution consiste à générer soit-même la requête à transmettre au serveur et d’analyse la réponse. Cela peut être fait avec l’instruction fsockopen. Mais il faut tout faire, générer la requête, la transmettre, recevoir la réponse et la traiter.
La requête doit être du type HEAD pour n’avoir que l’entête.
Après avoir fait divers tests, cette dernière solution semble la plus rapide.
Voir les temps de réponses pour savoir si le dossier l est présent sur le serveur web local (CF code en annexe) :
file_get_contents HTTP/1.1 200 OK 2.0584919452667s get_headers HTTP/1.1 200 OK 1.8262121677399s curl 200 0.006443977355957s fsockopen 200 0.0010509490966797s
Le dossier en question contient 24000 fichiers.
Il est clair de fsockopen est la solution la plus performante. C’est celle qui sera utilisée.
Je ne traite pas le cas des renvois type 301 puisqu’il n’est pas prévu pour l’instant dans la librairie nebule de suivre ces renvois.
Gestion des modules
La gestion des modules existait au niveau de sylabe. Elle est ajoutée directement dans nebule en PHP. Ce qui permet de l’utiliser à la fois dans nebule et sylabe. Chaque programme peut utiliser ses propres modules.
La programmation orientée objet dans PHP permet de gérer plus facilement des modules puisque ce sont simplement des classes, une par module, qui respectent des interfaces précises et non des fonctions multiples par modules. Le mécanisme de gestion derrière consiste à recenser les classes qui respectent certains critères et les lister dans un tableau, pré-instanciées.
La pré-instanciation permet d’initialiser certains environnements comme un accès à une base de donnée par exemple.
Il y a deux niveau de gestion en fait.
Le premier se fait au niveau de nebule. L’instanciation de la classe nebule va rechercher tous les objets qui sont définis comme des modules, c’est à dire avec le bon type et qui sont liés uniquement par l’entité bachue. La recherche des modules se fait en mode strict, les autres entités sont ignorées sauf les entités marquées comme autorités locales.
Le deuxième niveau, toujours lors de l’instanciation de la classe nebule, va appeler une classe spécifique par catégorie de modules. Cette classe est dite classe de routage. Pour chaque catégorie de modules, la classe de routage va s’occuper de rechercher toutes les classes correspondants à des modules ayant la même interface.
La classe de routage respecte la même interface que les classes des modules concernés. Elle seule est définit et reconnu dans l’instance nebule. Et c’est elle qui, étant appelée, va transmettre les requêtes vers la classe, le module, la plus appropriée au traitement. Elle fait donc les rôles de découverte des modules et de routage vers ces modules. Comme la classe de routage partage la même interface, elle a le même comportement que celles-ci, ce qui facilite le développement.
Il existe actuellement deux classes de routages reconnues : io et social.
La classe communication a été fusionnée dans io n’existe plus.
Il y a cependant un problème. En intégrant les IO dans des modules à charger, on se coupe l’herbe sous les pieds puisque pour charger les modules il faut avoir des IO fonctionnels… alors que ces IO sont dans les modules que l’on veut charger…
Là , le bootstrap va nous aider puis qu’il contiendra la classe d’un module IO par défaut, les IO sur système de fichier (FileSystem). Lors du chargement de la librairie nebule en php, une nouvelle détection se fera mais sur les modules présents localement, c’est à dire sur le système de fichier.
Ce fonctionnement par défaut avec le bootstrap entraîne un autre problème. Puisque l’on va utiliser le module IO FileSystem par défaut, on ne prendra en compte que ce qui y est présent. Si la libraire charge par défaut un autre module IO, par exemple MYSQL, alors les mises à jours des objets, et donc des modules, ne seront pas écrit sur le système de fichiers, et donc ceux-ci ne seront pas mis à jour.
Il faut prévoir un mécanisme de mise à jour…
Avancement
L’implémentation du bootstrap en PHP orienté objet avance. Voici à quoi ça ressemble :
Voici les classes et interfaces actuellement utilisées :
- class nebule
- class Object
- class Entity extends Object
- class Localisation extends Object
- class Link
- interface ioInterface
- class ioFileSystem implements ioInterface
- class Metrology
- interface CryptoInterface
- class CryptoOpenssl implements CryptoInterface
- interface CommunicationInterface
- class Communication implements CommunicationInterface
- class CommunicationHTTP implements CommunicationInterface
- interface SocialInterface
- class SocialStrict implements SocialInterface
Il est question de fusionner les classes Communication dans les IO. Les IO sur HTTP, SMTP et XMPP seraient des IO en lecture seule. Et surtout, ce serait des modules optionnels là où un module tel que ioFileSystem serait obligatoire. A moins que tout module d’IO ne soit valable et que l’instance ne fonctionne que avec des objets et liens sur un serveur HTTP ou XMPP autre, idée à creuser…