Catégorie : sylabe

Dissimulation, transcodage et dossier privé

La réflexion de l’article Anonymisation/dissimulation des liens – transcodage est très intéressante parce qu’elle rejoint la réflexion originel de nebule implémenté en bash pour les expérimentations. Cette implémentation en bash est clairement mono-entité, c’est à dire à l’usage exclusif d’une entité là où une implémentation en php comme l’application sylabe permet un usage multi-entités simultané.

L’implémentation en bash utilise un dossier nommé /pub pour recevoir les dossiers o et l contenants les objets et les liens dits publiques, ou plutôt publiables. Ce dossier /pub peut être partagé via un serveur web. Mais il y a aussi un dossier nommé /priv qui lui reçoit des dossiers o et l contenants les objets et les liens dits privés, donc non publiables. Le dossier des objets privés permet de recevoir le contenu des objets protégés et déchiffrés le temps de leur utilisation. Le dossier des liens privés n’a jamais été utilisé mais il correspond tout à fait à ce que l’on essaye de faire aujourd’hui avec le transcodage pour les liens de dissimulation.

La structure typique des dossiers de l’implémentation en bash :

/home/user
   +-> /neb
       +-> /pub
       |   +-> /l
       |   +-> /o
       +-> /priv
           +-> /l
           +-> /o

Or le problème de la dissimulation est facile à résoudre sans transcodage dans l’implémentation bash. Mais ce n’est pas transposable dans l’implémentation en php à cause de la notion cité plus haut de capacité multi-entités simultané. Les fichiers transcodés contenants les liens dissimulés répartis par ID d’objets sont le pendant direct des liens du dossier /priv/l.

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.

Soi-même ou moi-même

Dans la partie gestion sociale de la bibliothèque de nebule, il y avait peu de sous-parties dédiées à des calculs sociaux des liens. Il y avait notamment une partie self dédiée à la reconnaissance de ses propres liens, et son inverse notself pour exclure ses propres liens d’une recherche.

Cependant, la bibliothèque reconnait en quelque sorte deux type de soi. Il y a le soi de l’entité connectée et le soi de l’entité que l’on regarde. En quelque sorte un moi et un soi. Quand on désigne moi-même il est fait explicitement référence à ma personne, ou dans notre cas à son entité. Alors que le soi-même désigne le moi-même d’une personne, qui peut être quelqu’un d’autre, dans notre cas une autre entité.
Dans la bibliothèque, cette distinction apparaît dans la place de deux variables qui portent le même nom $currentEntity. Utilisée dans la classe très généraliste nebule, elle désigne l’entité connectée (déverrouillée). Utilisée dans la classe Applications elle désigne l’entité que l’on regarde, de la même façon que l’on désigne un objet que l’on regarde.

Cela a mené à devoir dissocier le traitement social pour refléter cette distinction. Ainsi self et notself références maintenant l’entité que l’on regarde (au travers d’une Application). Et myself et notmyself désigne l’entité connectée elle-même, c’est à dire l’entité active.

Ce comportement peut parraître subtil mais il prend tout son sens dans l’application messae et le module messagerie de sylabe. en effet, l’affichage de la liste des conversations se fait par rapport à une entité, donc des conversations de soi-même d’une entité. Mais si on ne précise pas d’entité alors c’est de l’entité connectée que l’on parle, donc soi-même.

D’autres types de traitement sociaux des liens seront ajoutés plus tard. Il faudra notamment trouver un moyen de pondérer les liens de ses amis…

Non vérification crypto et lecture seule

Dans la réflexion de créer une application dédiée à la manipulation de photos et de vidéos se pose invariablement la question des vidéos HD, FHD et UHD. La taille de ce genre de vidéo, pour conserver une qualité de restitution optimale, est assez conséquente.

Le problème ici dans nebule c’est la vérification systématique de la validité du contenu d’un objet manipulé, c’est à dire le re-calcul de son empreinte cryptographique. Si la librairie nebule mémorise le temps d’une session un objet vérifié, dans un cache, ce qui peut déjà présenter un problème de sécurité, il faut cependant toujours faire cette prise d’empreinte au moins une fois.
Par exemple l’empreinte SHA256 d’un fichier de 1,6Go va nécessiter environ 30s sur un disque dur à plateaux normal. La consommation de temps vient principalement de la lecture du support et non du calcul cryptographique. Et la prise d’empreinte cryptographique est un calcul relativement simple…

Il peut en être de même avec les liens qui nécessitent une vérification de signature de type RSA ou équivalent. Ce calcul en cryptographie asymétrique est beaucoup plus long rapporté à la quantité de données. Si un lien ne faire que quelques kilo-octets tout au plus, le nombre de liens à vérifier pour un seul objet peut être potentiellement gigantesque. Au cours du développement des applications de nebule il n’est pas rare de devoir nettoyer à la main les liens de la bibliothèque parce qu’il y en a plus de 80.000 … soit systématiquement 80.000 lien à lire et à vérifier. Là aussi un cache des liens déjà validés dans la session est en place pour accélérer le travail mais ce n’est pas toujours suffisant.

Une possible résolution de ce problème peut être de changer de disque et de passer sur SSD, ou de nettoyer sévèrement les liens utilisés. Mais ces deux cas sont extrêmes et pas toujours réalisables.

Une autre solution peut être envisageable dans le cas de machines de relais ou de partage d’informations en particulier. Comme on l’a vu dans l’article Frontal et relai d’information verrouillé en écriture, il est possible d’avoir des serveurs en lecture seule en activant l’option de lecture seule ou en figeant le système de fichiers. Cela pose des contraintes particulières sur la synchronisation des objets et des liens et sur le fait qu’ils doivent être vérifiés à un moment ou à un autre. Dans ce cas on peut coupler une option de non vérification des objets et des liens avec une option de lecture seule.
Avec cet exemple une entité peut toujours d’authentifier afin d’accéder à du contenu protégé mais ne pourra réaliser aucune action.

On peut imaginer aussi que l’application de mise à jour (upload) peut être autorisée à mettre à jours des liens et des objets en les vérifiant et ainsi avoir un serveur partiellement en lecture seule.

Donc il serait possible d’avoir un serveur de relai d’information en lecture seule uniquement mais avec un fonctionnement accéléré.
Ceci n’est pas implémenté actuellement.

Le message et le messager

Dans sylabe, il y a une implémentation de la messagerie.

Mais la messagerie tel que l’on a l’habitude de l’utiliser est un peu réductrice dans sa forme. L’article d’un blog comme le commentaire sur un réseau social sont aussi des formes de messages. Dans nebule, il est fort probable que ce soit la même information mais avec une présentation différente.

Dans un système de gestion de l’information dans lequel chaque information est intégrée dans un fichier avec ses usages, c’est à dire ses méta-données, une information transmise pour un nouvel usage devient un nouveau fichier. C’est le cas par exemple de la messagerie dans lequel un message retransmit à une nouvelle adresse devient un nouveau message alors qu’il contient la même information à la base. La différence, c’est que les destinataires du premier message ne sont pas forcément au courant du nouveau message et donc du partage de l’information. Ce non partage de certaines informations de diffusions (méta-données) est géré dans nebule par la mise en place de l’offuscation des liens.

La transmission d’un message c’est simplement la transmission d’une information. Ce qui permet au destinataire de savoir qu’une information lui est destiné c’est le fait de l’inclure dans un lien entre cette information et un objet dédié qu’il scrute. L’objet dédié est de fait un groupe d’objets lui étant destinés, ce qui s’apparente à un salon de discussion d’une messagerie. Ce salon de discussion est désigné par le terme de conversation contenant des messages.

Le mécanisme des conversations mis en place étant un retour à la sources des informations et de leurs usages, cela offre beaucoup de possibilités et de nouvelles perspectives. Une conversation peut être fermée et publique, elle est ainsi visible de tout le monde mais seules certaines personnes vont pouvoir légitimement et publiquement dialoguer dans cette conversation. Toute entité qui ne fait pas partie de la conversation fermée peut émettre des messages dans cette conversation mais ceux-ci ne seront pas vus pas les autres entités à part peut-être ses amis. Un groupe d’amis peut donc commenter en directe une conversation fermée sans perturber le déroulement de celle-ci pour les autres écouteurs de la conversation. Le statut d’une conversation peut être changé par un participant, cela n’impacte pas les autres participants, ce dernier peut ainsi décider de passer la conversation en ouverte et voir maintenant la contribution de tout le monde et non plus seulement les participants… sans plus gêner pour autant les participants.

Un nouveau problème arrive, comment présenter dans une interface ces fonctionnements à l’utilisateur, et de façon intuitive ?…

Définition des groupes

La gestion des groupes est entièrement revue et corrigée dans la bibliothèque nebule en PHP orienté objet et dans les applications (sylabe, klicty, messae).
Une fois les applications mises à jour, les groupes existants disparaîtront.

Cet article invalide la définition de groupe telle que définit dans l’article Définition des groupes du 14/01/2016.

Cette implémentation des groupes sera aussi utilisée pour les conversations contenant des messages.

OG / Groupe

Le groupe est un objet définit comme tel, c’est à dire qu’il doit avoir un type mime nebule/objet/groupe.

Fondamentalement, le groupe est un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Mais la définition du groupe doit être plus restrictive afin que celui-ci soit utilisable. Pour cela, dans nebule, le groupe n’est reconnu comme tel uniquement si il est marqué de son type mime. Il est cependant possible d’instancier explicitement un objet comme groupe et de l’utiliser comme tel en cas de besoin.

Le groupe va permettre de regrouper, et donc d’associer et de retrouver, des objets. L’objet du groupe va avoir des liens vers d’autres objets afin de les définir comme membres du groupe.

Un groupe peut avoir des liens de membres vers des objets définis aussi comme groupes. Ces objets peuvent être vus comme des sous-groupes. La bibliothèque nebule ne prend en compte qu’un seul niveau de groupe, c’est à dire que les sous-groupes sont gérés simplement comme des objets.

Continuer la lecture de Définition des groupes

Référencement par défaut

Suite des articles Références d’images, Propriété d’un objet et référence par rapport à un objet et Objet de référence contre suivi du graphe des mises à jours.

La recherche par référence se fait par rapport à un contexte. Ce contexte est définit par le champ méta des liens.

Pour les images, le contexte est définit par un objet contenant ‘nebule/objet/image/reference‘, soit l’ID 1ca96e517fc6ccca45080244c594dd777dc5d3bde0f872f961c28a4e9749ba82.

Pour la bibliothèque nebule en php, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/bibliotheque‘, soit l’ID 4297b53cfab1fc41f7820a47d1c21fbf7d0ab83a5ee4f94331c1e0ba1cbb99cf.

Pour les applications, le contexte est définit par un objet contenant ‘nebule/objet/interface/web/php/applications‘, soit l’ID e0150ff815bd5343034ff025624d20f723e2293842ab4eaedabda1ea5790e66b.

Etc…

Mais il n’y a pas que des usages dans des contextes techniques qui sont à prendre en compte. On peut permettre à l’utilisateur de gérer ses références. Pour cet usage un objet de référencement ‘nebule/reference‘ est dédié, soit l’objet 7339ea8fd26c67c3857ca94f9bac47d3841a3b75e799609720b8cc739732a161. La version publique actuelle de sylabe ne le reconnaît pas encore mais c’est le cas dans la version en cours de développement.

La reconnaissance des liens pour les références ne va pas être faite tout à fait de la même façon en fonction de l’usage. On doit être plus restrictif sur les références concernant les applications que pour celles de l’utilisateur. On va se base sur un calcul social de tri différent.

Et pour faciliter la gestion des références par l’utilisateur, un module dédié est en cours de développement. Il est dédié aux utilisateur donc il se base par défaut sur l’objet de référencement dédié aux utilisateurs mais peut très bien se baser sur d’autres objets de référencement.

Enfin, un lien de référence pourra être dissimulé.

Chargement de liens

Les applications génèrent par elles-même les liens dont elles ont besoin pour répondre aux usages des utilisateurs.

Il est possible de transmettre des liens qui ne peuvent être générés localement. C’est le cas des mises à jours d’applications.
Pour cela, il existe deux méthodes et deux moyens. Le code correspondant à été ré-écrit dans la bibliothèque nebule.

Pour qu’un lien soit traité, il faut que les trois soit validées :

  1. permitWrite : permet d’écrire des objets ou des liens.
  2. permitWriteLink : permet d’écrire des liens.
  3. permitUploadLink : permet de charger des liens.

Les deux méthodes sont :

  • le transfert d’un lien individuel ;
  • le transfert d’un fichier contenant (potentiellement) plusieurs liens.

Les deux moyens sont deux possibilités de transmettre les liens :

  • via l’application upload directement ;
  • via le module module_upload de l’application sylabe.

Lors du chargement d’un lien, quelque soit la méthode ou le moyen, le lien est d’abord vérifié structurellement.
Ensuite la vérification de la signature du lien et de son signataire répond à un processus plus complexe dépendant de deux options et de l’état de connexion d’une entité :

  1. permitPublicUploadLink : permet de charger des liens signés sans qu’une entité en cours ne soit déverrouillée, quelque soit le signataire.
  2. permitPublicUploadCodeMasterLink : permet de charger des liens signés par le maître du code (bachue) sans qu’une entité en cours ne soit déverrouillée.
  3. $this->_unlocked : variable qui donne l’état de déverrouillage de l’entité en cours d’utilisation, càd qu’une entité est connectée.

Si l’entité locale est déverrouillée, le transfert d’un lien devient une action légitime de l’entité. Tous les liens signés sont écrits si ils sont valides (structure et signature). Tous lien non signé est ré-écrit et signé par l’entité en cours; puis écrit.

Cette ré-écriture de lien est une ré-appropriation du lien. Est-ce que cette ré-appropriation peut poser problème ?

bootstrap – Mise en ligne

Une nouvelle 020170508 version du bootstrap est mise en ligne.

Le développement continue sur l’application option avec sa séparation de la gestion des autorités globales et locales.

La réflexion est toujours en cours sur l’avenir des autorités globales mais les autorités locales vont sûrement être scindées en plusieurs rôles sous des dénominations différentes.

Pas d’installateur complet pour cette fois, les deux applications sylabe et klicty sont mise à jour.

Le code est disponible ici :

94373583d31df5241fdf19de50be0e65fb6f65387188866818aebadd5a7217c5

Modification de l’ordre de prise en compte des propriétés d’un objet

Je reprends progressivement le développement de nebule pour corriger le bugg de klicty et améliorer dans sylabe le module correspondant.
Et je tombe sur un problème non dans l’implémentation mais dans la façon dont on prend en compte les propriétés d’un objet, ou plutôt l’ordre de prise en compte lorsque cela est fait plusieurs fois. C’est à dire, quel propriété retient-on en priorité lorsqu’il y a plusieurs liens d’un objet vers plusieurs propriétés.
Le problème n’a pas une solution difficile en soi mais le fait qu’il concerne une brique importante de nebule me freine à le modifier sans plus de réflexion. Les implications que cela engendre peuvent être très importantes dans pleins d’endroits du code de la bibliothèque de nebule et des applications. Continuer la lecture de Modification de l’ordre de prise en compte des propriétés d’un objet

bootstrap – Mise en ligne

Une nouvelle 020161129 version du bootstrap est mise en ligne.

Cette version corrige les problèmes d’accès à l’application 0.

Le développement continue sur l’application option afin de la rendre plus facile à utiliser et pour ajouter de nouvelles possibilités.

Les icônes des émotions sont de retour dans sylabe et klicty.

Le code est disponible ici :

a9cd70c397af6c02ffc7cf964a89beaed941293cb8fca6ae80947161f7bc1465

bootstrap – Mise en ligne

Une nouvelle 020161123 version du bootstrap est mise en ligne, le différentiel :

bc3f2cf23e92fa55fca4f20307236d7653726f9f7ca4593589316f3b8bdb9a53

Comme c’est un différentiel, il faut importer les liens puis copier les objets, et enfin remplacer le bootstrap. La bibliothèque et toutes les applications ont été mises à jour.

L’application 0 semble avoir des problèmes sur certains serveurs. Les serveurs de test ne semblent par contre pas concernés. Le problème est en cours d’investigation…

Avancement du bootstrap

Une nouvelle version du code du bootstrap en php procédurale est diffusée :

6c902d8c29b965fde6d576ef04e5405c84b1353d01715c4fb96e561ba76e9114

Comme d’habitude, l’identifiant est sont empreinte sha256. C’est le seul code qui ne peut pas être signé.

Sauf problème de dernière minute lors des tests sur Internet, cette version est fonctionnelle et complète.

Il manque par contre les liens signés du maître du code bachue pour désigner la bibliothèque et les applications. Les différentes applications se lancent sauf sylabe qui coince sur un de ses modules. Lorsque l’ensemble sera à peut près stable, le tout sera mis en ligne.

Du fait des grands changements dans la gestion des arguments en ligne et des applications, les applications actuellement en ligne sur Internet ne sont plus compatibles avec le nouveau bootstrap.

Ajout d’émotions sur des objets – suite 6

Suite des articles sur l’Ajout d’émotions sur des objets et suites 1 2 3 4 5, et Liens d’émotions.

Les émotions sont maintenant fonctionnelles dans la version encore en cours de développement de la librairie des des applications comme sylabe ou klicty.

1joie1 2confiance1 3peur1 4surprise1 5triste1 6degout1 7colere1 8interet1

Une page dédiée à l’Iconographie dans nebule est créé afin de recenser les différents icônes utilisées par la partie affichage (display) de la librairie. La première rubrique concerne justement les icônes des émotions.

Voici à quoi ressemble les émotions sur un objet affiché dans sylabe avec plusieurs émotions de plusieurs entités :

020161001 sylabe_-_Dieu_Thor_-_2016-10-01_22.39.40

Ajout d’émotions sur des objets – suite 5

Suite des articles sur l’Ajout d’émotions sur des objets et suites 1 2 3 4, et Liens d’émotions.

Les émotions sont une façon de marque un objet avec les sentiments qu’il inspire à un être humain. Les émotions sont plutôt subjectives là où les avis sont beaucoup plus objectifs. L’intensité que l’on peut donner à une émotion est toujours strictement positive, le sens positif ou négatif est déjà porté par l’émotion elle-même.

Les émotions étaient fonctionnelles sur les objets dans la version 2014 de sylabe. Mais le code ayant été entièrement repris en php orienté objet elles n’avaient pas encore été ré-implémentées. Le nécessaire est en cours de remise en place directement dans la librairie afin que les émotions sur les objets soient utilisables dans toutes les applications.

Les avis ne sont pas maintenus.

En parallèle, la réflexion à long terme continue sur la pondération des objets en vue de leur suppression automatique au bout d’une certain temps. C’est la fonction d’oublie. Il faut que cette pondération soit aisée à utiliser, et surtout qu’elle ait du sens pour que l’utilisateur prenne le temps de le faire. Il est clair qu’un champs de quantification de l’importance d’un objet est difficile à appréhender et ne sera pas utilisé. La gestion des émotions devient en fait la solution évidente de pondération. De plus, la pondération d’un objet, qui représente en fait son importance, peut influencer et être influencée par l’importance des objets qui lui sont liés.
Sans pondération, la gestion de l’oublie sera chaotique et peu fiable, donc pas utilisée.

La facilité d’usage et la pertinence de la solution de gestion des émotions et leurs pondérations sont donc déterminantes pour leur adoption et leur utilisation mais aussi plus tard pour la gestion de l’oublie.

Il y a plusieurs façons d’aborder la pondération avec les émotions. Continuer la lecture de Ajout d’émotions sur des objets – suite 5

Objet virtuel avec r̫le РSuite

Suite de l’article sur l’Objet virtuel avec rôle.

En fait ces objets virtuels sont déjà utilisés dans sylabe et klicty mais on se contente actuellement de générer aléatoirement la valeur de l’ID des objets de références. Et la taille des ID est la même qu’une empreinte de 256bits.

C’est utilisé par les groupes, le code va évoluer pour réduire la taille d’aléa utilisé et ajouter une partie fixe ou moins aléatoire. C’est utilisé par les nÅ“uds mais ils vont disparaître. Et c’est utilisé par les arborescences, là aussi le code va évoluer.

La part d’aléa va être réduite à 64bits et un préfixe assez long sera ajouté pour avoir une taille d’ID entre 129 et 191bits.

Objet virtuel avec rôle

Jusque là, la très grande majorité des objets créés ont ou ont eu un contenu et donc une empreinte numérique unique leur correspondant. Cela a été le cas pour les images utilisées comme icônes dans sylabe par exemple.

Le problème par exemple avec l’usage direct de l’objet d’une icône fait que si on veut la mettre à jour ou tout simplement en utiliser une autre à la place il faut faire un lien de mise à jour. Or ce lien de mise à jour n’a pas de contexte, c’est à dire de champs méta dans le lien. Ainsi la mise à jour s’applique partout alors que ce n’était pas forcément le but recherché.

La solution est de ne pas faire référence directement à une image que l’on veut utiliser dans une application mais à un objet intermédiaire. Cet objet n’a même pas besoin d’avoir un contenu, il est virtuel puisque son empreinte est créé de toute pièce sans contenu. Et du fait du fonctionnement de nebule, il n’aura probablement jamais (dans un temps raisonnable) de contenu correspondant à son empreinte.

Ainsi, on ne référence plus dans une application des icônes mais des objets intermédiaires. Et les icônes à utiliser n’ont plus à être des liens de mise à jour u mais deviennent naturellement des liens de dérivation f avec comme champs méta l’objet intermédiaire ou l’objet de l’application. Je pense que l’objet intermédiaire est le mieux comme champs méta.

Comme l’empreinte de cet objet virtuel est purement indicative, on peut lui mettre n’importe quelle valeur de n’importe quelle taille. Il est cependant raisonnable de choisir une taille assez conséquente et différente des tailles usuelles des empreintes, c’est à dire différent de 64, 128, 224, 256, 384, 512, 768, 1024, 2048, 4096, etc…
Chaque application peut utiliser les mêmes valeurs pour ces objets intermédiaires ou choisir par exemple une valeur préfixe identique suivi de valeurs aléatoires jusqu’à avoir une taille raisonnable.

Version 020160830

Une nouvelle version 020160830 est publiée. Les changements étant assez profonds par rapport à la précédente version publiée, elle va subir une phase de test. Il n’est pas possible de mettre à jour une instance de serveur existante sans remplacer le bootstrap, c’est à dire le fichier index.php. Les sites web des applications sylabe et klicty seront mis à niveau progressivement plus tard.

La nouvelle version est diffusée pour l’instant sous forme d’une nouvelle installation d’instance de serveur.
Elle est disponible ici : 6b48a8ced09ef7ede2da001d8bf10a6fe5ad9d586ca1f1856eeec9fbc8ad4688

La procédure d’installation va être créée pour avoir quelque chose de complètement fonctionnel. Jusque là la procédure d’installation ne concernait que sylabe.

Les nouvelles applications option, upload et defolt sont disponibles à partir de cette version.

Les options sont maintenant en grande partie nébulisées dans la librairie, c’est à dire gérées par des liens. Le fichier nebule.env reste mais va permettre de figer les options que l’on ne voudra pas voir modifiée par les liens.

Messagerie indépendante

La messagerie était un module de sylabe et avait déjà évolué pour ressembler plutôt à des conversation intégrant des messages.

Une nouvelle application va être lancée afin de présenter les conversations dans une application indépendante de la même façon que klicty. Mais le module des conversations dans sylabe va perduré et les conversations et messages seront complètement interopérables. En fait, la nouvelle application reprendra la base fonctionnelle et modulaire de sylabe mais avec un affichage simplifié et avec uniquement les modules entité, objet, groupe et messagerie. L’affichage principal sera différent mais les modules devraient être exactement les mêmes.

Afin de faciliter la création de nouvelles applications et la réutilisation des modules existants, le code de la librairie à été assez sérieusement modifié afin de centraliser dans celui-ci un maximum de fonctions et classes communes. A ce titre, la forme interne des applications et des modules à été changée et devient incompatible avec les précédentes applications et modules.

La nouvelle application des conversations s’appellera messae.
Un blog est déjà actif pour suivre son développement : http://blog.messae.org/

Status expérimental

En 2012, le développement de la librairie nebule en bash avait montré que l’on pouvait manipuler facilement des objets avec des liens.

La mise en ligne de la dernière version (20160303) de l’application klicty en php montre que l’on peut en faire quelque chose de concret. Donc, le statut des projets nebule, sylabe et klicty passera de « expérimental » à « en développement » lors de la publication des prochaines versions.