Catégorie : http

Liens hypertexte et insertions

Liens hypertexte

Le lien hypertexte a fait le succès de l’Internet en permettant depuis un document HTML de pointer vers d’autres documents HTML, ou d’autres ressources, et sur d’autres serveurs à travers tout l’Internet. C’est tellement pratique que d’autres programmes reprennent le même principe, par exemple les outils de bureautique qui permettent de pointer vers des fichiers externes sur le réseau ou localement sur la machine.

Le lien hypertexte ou ses équivalents utilisent une balise dans le texte du document. Cette balise est interprétée par le programme exploitant le document pour l’utilisateur. Et à la place de la balise on montre à l’utilisateur un contenu descriptif sur la destination comme un texte ou une image.

Dans les objets manipulés par nebule, il est possible d’ajouter une balise propre à nebule. Cette balise ne peut pas être la même que pour un document HTML parce que les objets peuvent ne pas être exploités via une page web. La balise doit se déclarer comme balise nebule et faire référence à un objet avec un élément de remplacement. Dans le cas de l’application sylabe, la balise sera remplacée par un lien HTML pointant vers l’objet mais sur le même serveur web.

Ici pas de nécessité de localisation dans la balise parce que la cible, un objet, est une URI et non une URL. Et le protocole n’est pas précisé parce que c’est le programme qui génère l’affichage qui va se charger de choisir le moyen de renvoie, HTTP, FTP, SMTP, XMPP, etc…

Insertions

Mais de la même façon, une balise peut être utilisée pour non plus renvoyer l’utilisateur vers une ressource externe mais plutôt pour inclure une ressource dans l’affichage présenté à l’utilisateur d’un objet. On obtient ainsi plusieurs contenus affichés en même temps par l’intermédiaire d’un seul objet maître.

C’est ce qui est fait par exemple dans l’inclusion de parties dans une page d’un Wiki.

Cela veut dire que les objets contenus doivent être présents sur le serveur pour permettre un affichage complet. Dans le cas contraire il devra être montré clairement à l’utilisateur qu’une partie du contenu manque.

Chaque objet peut avoir une mise à jour. Il est judicieux pour un même objet maître de ne pas suivre les liens de mise à jour des objets contenus. Mais il est possible de générer et de suivre les mises à jour de l’objet maître intégrant celles des objets contenus.

Historique des liens générés

Il y avait dans la librairie nebule en php procédural une option permettant de copier au moment de leur écriture les nouveaux liens générés. C’est une forme d’historique qui vient en complément de la possibilité d’écriture des nouveaux liens signés dans les liens de l’entité signataire. Par défaut tout arrivait dans le fichier l/f qu’il fallait bien sûr penser à vider de temps en temps.

Mais cela n’avait pas été ré-implémenté. C’est maintenant fait dans la librairie en php orienté objet. L’option permitHistoryLinksSign permet d’activer cette fonctionnalité et est par défaut à false, soit désactivé.

C’est utile pour le développement puisqu’il suffit de récupérer les derniers liens des programmes en cours de développement pour les faire signer par une autorité de code (bachue). C’est plus facile que d’aller faire la pêche aux liens sur les différents objets concernés.

Gestion des applications au niveau du bootstrap

Le bootstrap était jusque là assez sommaire. Il se contentait de trouver la dernière version valide de l’application en cours puis la chargeait pour affichage à l’utilisateur. Une page spécifique permettait, et permet toujours, de voir les caractéristiques du bootstrap et de son travail à des fins de dépannage, mais sans interaction possible.

20151018 nebule_bootstrap_-_2015-10-18_23.19.21
La page de dépannage du bootstrap. Continuer la lecture de Gestion des applications au niveau du bootstrap

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.

Continuer la lecture de IO HTTP et performances dans PHP

Avancement

L’implémentation du bootstrap en PHP orienté objet avance. Voici à quoi ça ressemble :

shot-2014-08-20_23-44-45

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…

Téléchargement et pondération – Protocols multiples

Suite des articles Téléchargement et pondération et activation.

Jusque ici, on utilise que le protocole HTTP. C’est simple, pratique et instantané.

Mais il était prévu que les objets et liens nebule puissent transiter par d’autres protocoles, notamment la messagerie.

On va prendre pour commencer le cas de la messagerie instantanée, et plus précisément XMPP qui est à la fois fonctionnel, ouvert et universel.
Contrairement à ce que l’on pourrait penser, l’utilisation de ce protocole est assez aisé. Il faut gérer une connexion TCP, transmettre des messages pré-formatés en XML et récupérer la réponse toujours en XML.
Ce qui est plus problématique par contre, c’est qu’une instance de nebule soit bidirectionnelle, c’est à dire qu’elle soit aussi serveur. Pour qu’elle puisse être serveur, elle doit fonctionner en permanence, or en HTTP, une fois la page chargée, tout s’arrête jusqu’à la prochaine page demandée.
Il faut utiliser un serveur XMPP sur lequel se connecte un autre programme. Ce programme agira comme tout client XMPP et fera la traduction vers les spécificités nebule, en gros répondre aux demandes d’objets et de liens.
Le serveur XMPP peut garder des messages pour les clients déconnectés. Pour le côté programme serveur de nebule, ça n’a pas d’intérêt, ils peuvent être supprimés lors de la connexion initiale au serveur XMPP. Par contre, côté client nebule, ce pourrait être des réponses à des requêtes précédentes. Mais si l’on respecte le sens des échanges, on ne doit accepter que les réponses correspondantes à des requêtes, et donc il faut suivre ces requêtes.

On continue avec le protocole de messagerie SMTP. Contrairement à XMPP vu précédemment, la messagerie SMTP n’est pas temps réel, c’est à dire instantanée. C’est même pire, elle a une contrainte de temps très large. Et ceci même si un message peut traverser le monde dans la seconde. Ce qui est à son avantage en temps normal est un problème dans notre cas.
On peut donc l’inclure dans les protocoles en espérant que les réponses seront rapides.
Un autre problème, c’est qu’il faut travailler avec un serveur de messagerie tiers avec deux voir trois protocoles différents. En effet, le SMTP ne sert qu’à l’envoi, la réponse doit être consultée avec POP ou IMAP.
Difficile donc d’implémenter facilement ce protocole. Il faudrait presque refaire un serveur dédié à nebule, ce qui serait plutôt improductif…

Il va falloir maintenant normaliser pour chaque protocole les requêtes/réponses.

Évidemment, la liste supportée n’est pas fermée. D’autres protocoles pourront être ajoutés par la suite…

Echanges via http – suite

Suite du post Echanges via http.

Si la définition des échanges dépend plus de nebule que de sylabe, c’est une erreur de mélanger les deux.

En effet, nebule a bien vocation à définir les téléchargements de liens et d’objets, notamment via http. La confusion vient que si sylabe passe par ce même protocole http vers les mêmes serveurs, les deux ne doivent pas être mélangés dans leurs rôles. Le projet sylabe doit être vu comme une application cliente qui repose notamment sur des échanges nebule mais doit utiliser ses propres accès pour son fonctionnement. C’est donc le cas pour lire les objets dans le navigateur web, surtout si ceux-ci ont nécessités d’être déchiffrés.

Les échanges via nebule ne doivent à aucun moment permettre le téléchargement d’objets nécessitant préalablement un déchiffrement.

Donc le programme index.php ne se chargera pas de gérer les translations de requêtes http (.htaccess pour Apache). Si sylabe (ou tout autre programme) en a besoin, il doit de lui-même mettre en place tout ce qui est nécessaire à son bon fonctionnement.

Echanges via http

L’avancement de sylabe met en avant un manque de standardisation des échanges nebule via le protocole http. Cela impacte notamment directement le téléchargement et le suivi de liens u.

Il faut compléter la documentation de référence nebule v1.1 concernant les moyens et supports d’échange.

Comme la définition des échanges dépend plus de nebule que de sylabe, c’est naturellement le programme index.php qui se chargera de gérer les translations de requêtes http (.htaccess pour Apache).

Il en sera de même pour tout nouveau protocole d’échange lorsque le besoin s’en fera ressentir. Cela pourra être le cas par exemple pour le xmpp et le smtp…