bitobi-arch
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bitobi-arch] [posts] unicité des norl oges et ordre des posts


From: Olivier Lourdais
Subject: Re: [Bitobi-arch] [posts] unicité des norl oges et ordre des posts
Date: Sat, 11 Jan 2003 16:28:00 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

Aurélien DEHAY wrote:

Le problème, c'est qu'avec l'archi bitobi, les modifications de
numéros mineurs vont être beaucoup plus fréquents si on n'y prend pas
garde. Et si je recopie une horloge avec numéro min et qu'il n'est pas
valide pour celui qui lit (ce qui n'arrive qu'exceptionnelement
aujourd'hui) c'est chiant quand même.

J'ai pas tout compris.

[...]

cf mon autre mail

La technique que j'avais proposée assurait justement la compatibilité
avec les coincoins existant :)

Cf supra. Pas tout compris.

pareil

Or, le backend actuel ne fait pas de distinction la dessus,
c'est le coincoin qui le fait. Pour avoir le meme tri, je pense que se
baser sur un tri sur horloge ET sur le MD5 resoud le probleme.

Ah non, là je m'insurge, le md5 ne résoud rien du tout !
si j'ai :
[h=42:42:42 md5=42...424] == 42:42:42-1 : "plop"
[h=42:42:42 md5=42...426] == 42:42:42-2 : "pika"
et que je réponds au post que je vois comme étant le 42:42:42-2, il
est possible que je n'aie pas encore reçu le post [h=42:42:42
md5=42...425] : "prout" qui sera vu à terme comme le 42:42:42-2 !!!

Effectivement. Mais c'est deja le cas avec un bouchot normal.

Bah à part des bugs ou des choses comme ça, il faudra m'expliquer dans quel cas de figure ça peut intervenir.

Je ne vois pas comment un tri arbitraire sur les posts en plus de
l'horloge pourrait résoudre ce problème.

Ben c'est ce qui se passe actuellement. Je ne sais pas comment est
fait le tri sur les tribunes actuelles.

Bah il me semble que les posts sont traités dans l'ordre dans l'ordre dans lequel ils arrivent (ce qui pour moi ne constitue pas un tri arbitraire).

[ Et d'ailleurs, pourquoi utiliser le md5 ? Ça doit faire un sacré
overhead quand même ! C'est moins coûteux d'utiliser directement le
contenu des posts. Ou mieux : l'adresse ip du noeud qui a daté le
message. ]

Avec ca on pourrait eviter les posts en double par exemple.

Si on applique un traitement pour éviter les posts en double, c'est pas au niveau de la génération du backend qu'il faut s'en occuper, mais dans l'interface de postage (et puis là aussi, ça serait moins coûteux de faire la comparaison directement sur le corps du post que sur son md5).

Et puis
c'est joli un MD5, ca fait hype.

Mouais :/

En fait ici (si on n'utilise pas ma technique ;), les numéros mineurs
apportent plus de confusion que de confort. La solution serait
peut-être de ne plus utiliser les numéros mineurs, mais je ne pense
pas que c'est acceptable, et ça nécessite de modifier les coincoins.

Gni?

Nan nan, c'était un truc en l'air, j'étais pas sérieux ;)

Lourde c'est le mot... Sinon, y'a Spread, qui est une lib toute prete,
mais avec une licence bizarre. (J'ai plus le site sous la main, STFW).

Bah justement c'est précisément cette artillerie lourde qui est
utilisée par Spread, j'ai l'impression --> trop coûteux, pas adapté.

De toutes facons, le probleme est regle :)

Bah si on arrive pas à se comprendre plus que ça, je suis pas sûr :/






reply via email to

[Prev in Thread] Current Thread [Next in Thread]