Archive for the ‘modules’ Category

Intégration des groupes dans la librairie php – suite

Dimanche, février 21st, 2016

Suite à l’intégration des groupes dans la librairie php, l’ensemble est fonctionnel et stable dans la librairie ainsi que dans klicty.

Intégration des groupes dans la librairie php

Lundi, février 1st, 2016

Suite à la définition des groupes, l’intégration a commencé dans la librairie php orienté objet.

L’intégration est profonde puisque les groupes sont gérés comme des objets spécifiques comme c’était déjà le cas pour les entités. Une classe dédiée ainsi que tout un tas de fonctions leurs sont dédiés et personnalisés.

Les applications sylabe et klicty vont intégrer progressivement les groupes, notamment dans un module adapté.

Dans le même temps, un groupe fermé étant uniquement constitué de liens d’une seule entité (et cela doit être vérifié), le filtre social est en cours de mise en place. Ainsi, il est possible de restreindre la prise en compte des liens suivant ces filtres sociaux :

  • self : liens de l’entité ;
  • strict : liens de l’entité et des entités autorités locales ;
  • all : toutes les entités, mais avec un classement par pondération des entités.

L’activation du filtre social et donc de la possibilité de le choisir dans le code à nécessité un revue de tout le code de la librairie et des applications. Il reste à vérifier les modules de sylabe.

Arborescence virtuelle

Samedi, novembre 29th, 2014

Dans nos systèmes d’information actuels, le rangement des fichiers dans une arborescence est non seulement classique mais fondamentale et souvent incontournable. L’autre forme de rangement est d’utiliser une base de données.

Il est possible avec nebule de simuler une arborescence mais virtuelle et uniquement constituée d’objets et de liens.
CF Wiki – Réflexion – analyse des applications – Système de fichiers

Un arborescence commence par une racine, par exemple ‘/‘. Dans cette racine on va trouver des fichiers, des sous-dossiers et des fichiers dans les sous-dossiers.
Chaque fichier a nativement un nom ou au pire un identifiant unique. Les fichiers vont avoir en plus un ou des liens pour les positionner dans l’arborescence à un ou plusieurs endroits.
Chaque dossier est constitué de l’objet contenant son nom. Cet objet de nommage est lié au dossier parent par un lien, lui-même relié à son dossier parent… jusqu’à la racine.

Le nom des objets ne pose pas de problème, il risque juste de changer d’une entité à l’autre. Le nom d’un dossier peut par contre avoir deux formes, mais on ne doit en gérer qu’une seule.
Soit le nom d’un dossier ne contient que sont nom et pas l’ensemble de l’arborescence. Dans ce cason peut avoir n’importe quel nom, y compris des noms avec le caractère séparateur de dossiers ‘/’. Mais si on souhaite mettre deux dossiers avec le même nom dans deux branches différentes de l’arborescence, il y a conflit sur le nom et donc mélange des fichiers enfants.
Soit le nom d’un dossier contient l’ensemble de l’arborescence. On résoud les problèmes de conflit. Et on n’accepte pas des noms de dossiers avec le caractère séparateur de dossiers. C’est la meilleur solution.

Comme il est possible que plusieurs entités créent plusieurs arborescences différentes ou en reconnaîssent plusieurs, il faut un objet unique de référence de cette arborescence. L’objet contenant ‘/’ doit dans ce cas être lié à l’objet de référence, et il en est de même pour tous les objets de l’aborescence.
Ainsi, comme pour l’émulation de commentaires dans le blog, les objets on des liens entre eux avec comme contexte un objet de référence. Les mêmes liens peuvent tout à fait être reproduire intégralement ou partiellement avec un autre objet de référence et ne pas entrer en conflit.

On obtient, du fait même de la base nebulisée, des comportements spécifiques sur l’arborescence.
Par exemple dans une arborescence de fichiers d’une société, le chef pose un nouveau fichier dans un sous-dossier. Tout le monde dans la société va voir ce nouveau fichier. Un des employé ‘copie’ le fichier ailleurs dans l’arborescence, tout le monde voit le nouveau fichier. Si il le modifie, il crée un objet de mise à jour et les deux fichiers sont mis à jours. Cela est intéressant puisque tous les emplacements sont tenus à jours mais cela peut déjà poser problème puisque l’on ne voulait peut-être pas tout mettre à jour. Il faut donc bien distinguer la mise à jour et le dérivé.
Prenons un autre cas. Un des employé modifie le nom du fichier créé par le chef. tout le monde voit la modification. Le chef décide d’annuler le nouveau nom, de redonner le nom d’origine au fichier. Tout le monde va voir le fichier revenir à son nom d’origine… sauf peut-être celui qui avait renommé le fichier puisque la gestion sociale des liens va peut-être décider que personne ne peut annuler son opération, même si le chef est son supérieur hiérarchique dans la société.

Cette arborescence virtuelle sera ajoutée pour expérimentation à sylabe. Comme ce n’est pas quelque chose de vraiment natif dans la philosophie de nebule, l’implémentation se fera sous forme d’un module.

On peut ensuite, sur cette base, aller plus loin avec par exemple inotify. Pour un dossier spécifié et ses sous dossiers, tout changement sur un dossier ou un fichier serait immédiatement nébulisé et synchronisé vers un serveur local ou distant.

Avancement

Dimanche, novembre 16th, 2014

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.

nebule_bootstrap_-_Experimental_-_2014-11-16_10.21.26

Gestion des modules – IO et gros objets

Dimanche, août 31st, 2014

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

Vendredi, août 29th, 2014

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.

(suite…)

Gestion des modules

Samedi, août 23rd, 2014

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…