Re: [Bitobi-arch] ordre des posts, plonkage, et remarques diverses

[Olivier Lourdais]

> gah, t'as raison.. depuis le début on dit qu'on connait le noeud
> d'origine du post, chuis trop con. bon, vendu en ce qui me concerne


\o/ oué, je l'ai eu à l'usure ;)


> | au temps pour moi
> | le changement de sous numéro j'ai déjà vu çà avec wmc² effectivement,
> | mais jamais avec pyc² par contre.
> | je vois pas trop d'où çà peut venir avec le fonctionnement actuel !

apparemment ce genre de problèmes surviendrait après un problème de slip 
ou de chaussette

> | en tous cas, garantir une norloge unique ne me semble pas dénué de sens
>
> je sais pas.. on a déjà un authentifiant unique, donc je dirais que ce
> n'est pas une pure nécessité.

bah, un tel id, c'est utilisable pour le calcul, mais pas pour la lecture
pour la lecture, je pense que les norloges uniques sont indispensables 
(même si les quelques problèmes de l'implémentation actuelle n'étaient 
pas trop gênant)
(et puis, encore une fois, si on par du principe que ce sont les 
norloges qui font l'originalité des tribunes, il faut s'efforcer de 
bétonner leur fonctionnement)

> Si on a un moyen raisonnablement simple de
> garantir une norloge unique par post, je plussoie, c'est clair que ce
> serait mieux.

j'aime pas tant que çà la solution que j'avais proposée (car elle 
implique un traitement entre l'envoi du post et sa diffusion puis entre 
sa dffusion et son affichage, et car elle rajoute de l'overhead), mais :
- ça me parait pas non plus trop cher en traitement, ni trop dur à 
implémenter
- ça me semble la moins mauvaise des solutions
- ça garanti imho une fiabilité parfaite des norloges (à condition que 
les utilisateurs ne les écrivent pas n'importe comment)
- ça conserve le format actuellement utilisé pour les norloges

> En même temps, pifométriquement parlant, ça me semble bien
> galère à gérer, et en tout cas je vois pas comment faire sans attendre
> que tous le bitobi soit synchronisé pour un temps t..

tu veux parler du protocole abcast, des horloges de lamport, tout çà ... ?
là c'est l'artillerie lourde
ça ma parait beaucoup trop coûteux, lourd et pas adapté (nombre de 
messages, latence, ...) pour être utilisable ici

> Mais bon, laissons
> le sujet ouvert, si quelqu'un a une idée de génie..

oué on sait jamais :)

> aaah.. okay, je vois ce que tu veux dire. En revanche, je ne suis
> toujours qu'à moitié convaincu. y'a-t-il vraiment un avantage à diffuser
> vers plus de node, plutôt que d'imaginer pour les noeuds 'passifs' un
> fonctionnement à la antigone? (récupération du xml comme n'importe quel
> mouling agent, et traitement spécifique).

bon, avec un fonctionnement à l'ancienne antigone, il faut se réveiller 
régulièrement pour consulter le backend
avec un noeud passif on a un genre de push (si la connexion reste 
ouverte, ça doit pas rentrer dans la définition de push, mais 
fonctionnellement ça s'en rapproche), on se rapproche du design "pattern 
observer", je me permets donc de citer l'argumentaire du bouquin de gamma :
-----
Intention
Définit une interdépendance de type un à plusieurs, de façon telle que, 
quand un objet change d'état, tous ceux qui en dépendent soient notifiés 
et automatiquement mis à jour.

[...]
Motivation
Un effet couramment induit par le partitionnement d'un système en une 
collection de classes coopérantes, est l'obligation de maintenir la 
cohérence des objets en relation. Il n'est pas souhaitable d'obtenir 
cette cohérence au prix d'un couplage étroit entre les classes, car cela 
réduirait leur réutilisabilité.
[...]
Le modèle observateur décrit comment établir de telles relations. Les 
objets de base de ce modèle sont le sujet et l'observateur. Un sujet 
peut avoir un nombre quelconque d'observateurs sous sa dépendance. Tous 
les objets reçoivent une notification chaque fois que le sujet subit une 
modification de son état. En réponse, chaque observateur interrogera le 
sujet sur son état afin d'y adapter le sien propre.[adaptation : on sait 
quelles informations intéressent les observateurs, donc on leur envoie 
directment]
Ce type d'interaction est également connu sous le nom de 
Diffusuion-Souscription. Le sujet diffuse les notifications. Il les 
expédie, sans avoir à connaître ses observateurs. Des observateurs, en 
nombre quelconque, peuvent souscrire pour recevoir les notifications.

Indications d'utilisation
On utilisera le modèle observateur dans les situations suivantes :
- Quand un concept a deux représentations, l'une dépendant de l'autre. 
Encapsuler ces deux représentations dans des objets distincts permet de 
les réutiliser et de les modifier indépendamment.
- Quand la modification d'un objet nécessite de modifier les autres, et 
que l'on ne sait pas combien sont les autres.
- Quand un objet doit être capable de faire une notification à d'autres 
objets sans faire d'hypothèses sur la nature de ces objets. En d'autres 
termes, quand ces objets ne doivent pas être trop fortement couplés.
-----
ça correspond grosso modo à notre cas de figure, je trouve
donc pour moi niveau design y'a pas photo

et ici par chance :
- les info qui intéressent les noeuds passifs (observateurs) sont les 
mêmes que les ibnfos à diffuser aux voisins
- les info produites pa les noeuds passifs sont les infos à diffuser aux 
voisins
au aurait tort de se priver d'une telle opportunité de simplification 
(=> même type de connexions)

> En terme de charge et de
> transit réseau, à quoi ressemblerait chacune des solutions?

un réveil inutile, ça fait un léger traitement parfois inutile
et idem pour la consultation : on a parfois des connexions et des 
messages inutiles
mais dans les 2 cas, ça ne doit pas être très coûteux
[question : qu'est ce qui coûte cher actuellement (qui fait tomber 
woof.lu) ? l'établissement des connexions (dans ce cas le modèle 
observateur est beaucoup mieux) ou le volume de données échangées (dans 
ce cas, l'obs est un peu meilleur) ?
remarque : si un service de type antigone est installé sur une machine 
qui a déjà un noeud, la conso en bande passante sera nulle dans les deux cas

> D'autre part, j'interprete peut-être mal ton schemas, mais il me semble
> que certains noeuds passifs seraient susceptibles de faire transiter des
> messages

noeud passif = producteur/consommateur de messages
noeud = diffuseur

> (par exemple depuis un coin² 2ème génération)

euh, non

> , et l'interface
> ouaibe a aussi l'air d'être un noeud passif..

ouaip

> là, du moins si
> j'interprète bien ton schémas, ça me gène un peu.. ça veut dire plus de
> noeuds à authentifier par clef, et donc agrandir le résal de confiance,
> ce qui me semble a priori pas une bonne idée, ou en tout cas être trop
> compliqué pour la fonction de ces nodes passifs.

nope
sur le schéma, le noeud passif qui sert de backend/interface web est sur 
le même site (càd bécane) que son noeud d'ammarage
on peut configurer le noeud pour qu'il ait une confiance absolue vis à 
vis des noeuds passifs qui sont sur la même bécane que lui (admin, 
antigone, interface quelconque, ...), à la limite on peut imaginer un 
mécanisme plus léger (sorte de cookie ?)
pour les noeuds passifs qui sont sur un auter site (coincoin de 2nde 
génération), l'authentification par cookie devrait suffire

> Je dirais à la louche
> que soit ces nodes passifs devraient utiliser le remote.xml, soit qu'ils
> devraient passer par des interfaces différentes des nodes 'normaux' (et
> qu'on devrait donc avoir un autre type de flèches dans ton crobard)
> ça vous semble avoir un sens?

on peut imaginer un traitement différent pour l'authentification à 
l'ouverture de la connexion, mais après surtout pas

> pas faux. en même temps, je préfererais que ce soit un cas particulier
> de couche de persistance, une qui aurait 0 capabilités (on partait de
> toutes façon sur des couches 'plugin' pour pouvoir persister
> indifférement sur un fs, une db, une autre db, etc..). ça implique juste
> que chaque plugin sache dire ce qu'il peut fournir comme service, ce qui
> de toutes façons est plutôt un bon design amha

genre des classes de service avec des paramètres associés ?
<noeud_passif blablabla>
 <service classe="persistance">
   <param nom="url_consultation" val="http://..."/>
 </service>
 d'autres services ?
</noeud_passif>
est-ce que c'est utile/indispensable ? moi je dirais plutôt oui
sinon, est ce que c'est raisonnable de permettre à un noeud passif de 
fournir plusieurs services ? là je dirais oui (on sait jamais) mais à 
déconseiller fortement (pour la simplicité, la modularité, la 
robustesse, tout ça ...)

> En plus, quand je parle de persistence, c'est pas nécessairement de la
> persitence à long terme non plus, sauf si on veut logguer pour repérer
> d'éventuels boulays.. ça peut être juste une table en mémoire, et du
> coup c'est la ram de ton hébergeur que tu vas pourrir ;)

quelques dizaines de posts, c'est encore raisonnable comme conso :)

> y'a encore à réfléchir du coup, je dirais.. peut-on prendre le parti de
> dire que tout est en ram et laisser tomber l'idée d'un stockage en
> db/fichier? pourquoi cela n'a-t-il pas été fait dans dacode et templeet?
> pour coller au reste du moteur, ou parce que sinon ça écroule les 
> machines?

je pense qu'ils ont mis en commun le support et les fonctions de log 
(pour les boulays) et de préparation du backend
comme il y a un cache, l'accès au backend/interface ouaibe se fait le 
plus souvent... en mémoire vive :)

> papier, ou un automate à tester? Moi je suis pour l'automate, mais c'est
> plus de boulot

pour le papier, ça sera la rfc(c ?), non ?
pour l'automatisation : [+] la préparation des tests avant/en même temps 
indépendamment de l'implémentation, ça rox (c'est pas une des règles de 
l'extem programming ?)
bon, après faut voir la charge de travail en plus, mais je pense que 
c'est gérable

> bon, donc sous-tache : définir des messages administratifs?

yep, on peut commencer à voir ça (pitet dans un autre thread)

> cf plus haut, pour ce qui est de considérer les noeuds passifs comme
> n'importe quel noeud

cf réponse plus haut

> effectivement, avec ta définition des noeuds passifs. Du coup en
> revanche, faut absolument que ces noeuds passifs là au moins fassent
> partie du résal de confiance, sinon c'est danjeureu

cf plus haut


autre chose : est ce qu'il est prévu d'avoir plusieurs niveaux de 
confiance ?
par exemple si une moule néophyte a un très bon hébergement et se 
propose d'héberger un noeud, qu'elle se fait signer sa clef et qu'elle 
rentre du coup dans le cercle de confiance, mais qu'elle n'est pas très 
aware et que le lendemain elle fait une gaffe en accèptant de signer la 
clef d'un membre de la dream team ?
l'utilisation de niveaux de confiance pourrait peut-être aider à 
empêcher ce cas de figure :
un newbie se voit accorder un niveau de 1, le niveau montera avec 
l'ancienneté, et à chaque intermédiaire dans la signature d'une clef le 
niveau de confiance décroit de 1 (ex : A signe la clef de B avec une 
confiance de 1, A est dans le cercle de confiance de C (avec un niveau 
de 5 par exemple), donc C accordera une confiance de 1-1=0 à B)
je dis une grosse connerie ? ça existe déjà ? c'est trop compliqué ?