Cette page n’est pas encore traduite : la version anglaise est affichée.
Social
Social ajoute une seule notion : une relation entre deux acteurs, avec son propre état et un initiateur. Un clan, une guilde ou une escouade est un groupe doté d’une couche de relations, pas une seconde sorte d’objet ; et le blocage, dont plusieurs modules ont besoin, vit ici pour qu’un seul endroit en soit propriétaire.
Quand l’utiliser
- Les joueurs doivent se retrouver par leur nom : amis, abonnés (follower), listes de blocage.
- Un groupe de type clan ou guilde a besoin de règles d’entrée : une invitation de la part du groupe, une demande d’adhésion de la part d’un acteur, et une décision sur l’une ou l’autre.
- Une liste d’amis doit montrer qui est en ligne : la présence se déduit des sessions, et qui peut la voir est un prédicat que vous déclarez.
- Un autre module doit savoir qu’un acteur est bloqué : il lit cet état ici au lieu de tenir le sien.
- Inutile quand il s’agit d’un ensemble d’acteurs plutôt que d’une paire avec un état : c’est un groupe, et un groupe par paire donnerait des millions de groupes de deux personnes, chacun avec son propre cycle de vie et ses propres règles d’entrée.
Qui fait quoi
| Acteur | Peut | Ne peut pas |
|---|---|---|
player | proposer une relation ou suivre quelqu’un (follow) ; accepter, refuser ou retirer ; rompre une relation mutuelle ; bloquer et débloquer ; lire ses propres relations et la présence des acteurs liés ; s’abonner aux changements ; soumettre une demande d’adhésion | lire la liste des relations de qui que ce soit d’autre, quelle que soit la relation qui les unit |
moderator | statuer sur les invitations et les demandes d’adhésion là où il détient la permission atomique d’administration des membres | statuer sur une demande pour laquelle il n’a aucune permission — la réponse est alors forbidden |
Le modèle
Ce que porte une d éclaration de relation.
| Déclaration | Ce que c’est |
|---|---|
kind | symétrique — la paire exige l’accord des deux côtés, et c’est d’elle que traite la machine à états ci-dessous ; ou unilatérale — le suivi, dont le seul état est active. L’unicité par paire et l’idempotence d’une proposition valent dans les deux cas |
règle de réinvitation | après un refus : interdite · autorisée après un délai déclaré · autorisée immédiatement. Elle se déclare, parce que « redemander » relève d’une décision produit |
visibilité de la présence | un prédicat — pour tout le monde · seulement pour les relations mutuelles · pour personne. Il n’y a pas de valeur par défaut |
mode d'adhésion (sur le type de groupe) | ouvert · sur demande, avec décision · sur invitation uniquement |
rétention des relations refusées et rompues | passé le délai déclaré, la relation est supprimée, et il redevient possible d’inviter, quelle que soit la règle de réinvitation |
Les états d’une relation symétrique.
| État | Signification |
|---|---|
proposed | l’initiateur a fait une proposition et l’autre côté n’a pas encore répondu |
mutual | les deux côtés sont d’accord |
declined | l’autre côté a refusé. La relation est conservée, car la règle de réinvitation en a besoin |
broken | l’un des côtés a quitté une relation mutuelle |
blocked | l’un des côtés a bloqué l’autre |
Ce qui vaut pour toute relation.
| Toujours | Ce que c’est |
|---|---|
une seule entité par paire | et non deux enregistrements en miroir. « A a fait une proposition à B » et « B a reçu une proposition de A » sont un seul et même fait, lu depuis deux côtés |
un initiateur | est déclaré : qui a proposé, une information dont ont besoin à la fois l’affichage et la règle de réinvitation |
blocked l'emporte | aucune transition ne mène de cet état à proposed ou à mutual |
un blocage | est asymétrique dans son contrôle, symétrique dans son effet : seul celui qui l’a posé peut le lever, et il agit dans les deux sens |
l'état de blocage | appartient à ce module et sert ailleurs : Messaging et d’autres le lisent ; aucun ne le modifie, et aucun n’en garde de copie |
la présence | se déduit des sessions : personne ne l’écrit, et le prédicat de visibilité s’applique à chaque demandeur plutôt qu’une fois pour toutes par acteur |
une demande en attente | n’occupe pas de place (seat) : une invitation ou une demande d’adhésion ne compte jamais dans la capacité du groupe, si bien que cent demandes ne peuvent pas saturer un clan de cinquante |
un groupe | garde toujours un administrateur : au moins un acteur doit détenir la permission atomique d’administration des membres, et le dernier ne peut pas simplement partir — un clan dont le dernier administrateur serait parti ne pourrait plus jamais admettre personne |
pas de rôles internes au groupe | un « officier de clan » est un acteur qui détient une permission atomique, pas un rang stocké dans une liste |
une importation n'écrase jamais rien | les relations importées depuis un fournisseur de connexion s’ajoutent à l’existant : une personne bloquée ne devient pas une amie parce qu’un fournisseur le dit |
Erreurs
- Une relation déjà mutuelle est un conflit : il n’y a rien à proposer.
- Une proposition à soi-même est un refus de validation.
- Si l’un des côtés a bloqué l’autre, la réponse est not found — et non forbidden, car un refus qui distinguerait les deux cas révélerait le blocage. Inutile de réessayer.
- Une réinvitation avant l’échéance est un conflit, qu’il vaut la peine de réessayer une fois l’échéance passée.
- Une limite atteinte — relations, demandes — est un conflit, pas une interdiction : la permission est bien détenue, mais il ne reste plus de capacité. Réessayez quand une place se libère, ou quand les demandes en cours ont été tranchées.
- Une demande expirée est un conflit : créez-en une nouvelle au lieu de réessayer l’ancienne.
- Le départ du dernier administrateur d’un groupe est un conflit tant que la permission n’a pas été transmise.
- Statuer sur la demande d’un autre sans la permission répond forbidden, et il est inutile de réessayer.
- Une importation depuis un fournisseur non connecté répond unavailable : réessayez avec un délai croissant (backoff).
Limites
Les valeurs chiffrées arriveront avec le chapitre sur les limites de la plateforme ; ce qui se passe à chaque plafond est déjà fixé.
- Relations mutuelles par acteur : une proposition est refusée comme conflit ; les relations existantes ne sont jamais rompues pour faire de la place.
- Relations unilatérales par acteur : une nouvelle relation est refusée ; les existantes restent.
- Propositions sortantes : une nouvelle proposition est refusée, et il n’y a pas d’éviction : une invitation évincée ressemblerait à une invitation refusée.
- Blocages par acteur : un ajout est refusé comme conflit, et les anciens blocages ne sont pas évincés, pour que personne ne soit débloqué en silence.
- Durée de vie d’une demande :
expired, avec un événement. - Fréquence des propositions par acteur : une limitation de débit (rate limit) avec un délai.
- Fréquence des changements de présence dans le flux : bornée par la fréquence de mise à jour, sans abandonner de changements.
- Rétention des relations refusées et rompues : suppression selon le délai déclaré.