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…