Liens des options

Le lien permettant de définir une option, si elle est autorisée à être modifiée, est constitué d’un type l, du nom de l’option, de sa valeur et d’un objet méta de référence nebule/option.

Cette forme de lien est bonne pour un usage locale et personnel des options. Mais il se prête mal à la gestion des options d’entités sous contrôle. Par exemple si on a un serveur de diffusion de contenu, on peut être amené à changer son comportement. Cette forme de lien impose dans ce cas de générer un lien avec l’entité instance du serveur… et donc de connaître obligatoirement son mot de passe.

Peut-être serait-il judicieux de changer maintenant la forme du lien pour inclure une entité. L’objet méta n’a pas grande utilité ici comme référence fixe. La référence pourrait devenir le nom de l’option… et les noms des options deviendraient des objets réservés.

Suite au prochain épisode…

Gestion du cache des objets et liens

La bibliothèque nebule gère maintenant mieux le cache des objets et des liens.

Jusque là tous les objets et liens lus étaient mis en cache. Cela pouvait conduire assez rapidement à une dépassement de la mémoire disponible pour un processus PHP.

Maintenant l’option sessionBufferSize permet de limiter la taille du cache. Par défaut l’option est à 1000. Cette limitation est tout compris, que ce soit les liens ou les différents types d’objets.

Chaque entrée du cache est maintenant datée de sa création ou de sa dernière re-création, c’est à dire à chaque fois qu’elle est utilisée. Au besoin, une place est faite dans le cache pour la nouvelle entrée en supprimant la plus ancienne, càd celle qui n’a pas été utilisée depuis le plus longtemps.

Et en fait cela accélère le calcul des pages parce que l’on a moins de choses à recharger de la session PHP.

Options de désactivation de protection et de dissimulation

La protection des objets est fonctionnelle. La dissimulation des liens des objets pas encore. Les deux sont implémentés dans la bibliothèque nebule.

Mais il y a désormais des options pour les désactiver, elles sont activées par défaut :

  • permitProtectedObject : Cette option active la possibilité de gérer la protection des objets et la possibilité de prendre en compte les liens de type k.
  • permitObfuscatedLink : Cette option active la possibilité de gérer la dissimulation (offuscation) des liens des objets et la possibilité de prendre en compte les liens de type c.

Lorsque une option est désactivée, le type de lien correspondant n’est plus géré, il est explicitement refusé. C’est à dire que les liens existants sont ignorés et les nouveaux liens sont rejetés comme invalides.

Ces options sont encore en cours d’ajout dans le code mais sont déjà fonctionnels pour les liens.

Filtre social de liens sur réputation du signataire

Dans les filtres sociaux des liens, deux nouveaux types sont ajoutés : reputation et unreputation

Cela permettra à terme le tri par rapport à la réputation d’une entité. Cependant, la pondération des entités n’étant pas implémentée, ces deux filtres sont pour l’instant équivalents au filtre social none.

Traitement social des liens sur liste

Typiquement, dans une conversation, on peut n’afficher les messages que de certaines entités. C’est le cas si on a marqué la conversation comme fermée.

Jusque là on listait les liens de tous les messages de la conversation puis le module filtrait les liens par rapport aux entités de la conversation.

Maintenant, la bibliothèque nebule intègre dans la partie calcul social deux nouvelles façons de filtrer les liens : onlist et offlist
Il faut préalablement envoyer au module de filtre social la liste des ID des entités que l’on veut garder ou filtrer puis appeler le filtre.

Cela centralise le processus et simplifie les applications et modules.

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…