mettez vos blagues et connerie.

[Klaim]

Ha ben oui, en JSP, ASP c'est possible, mais en PHP non, parcequec'est que des pages executées à la demande : tu peux pas faire du code qui serait executé lors d'un evenemetn, comme par exemple dans notre cas la fin d'une session.

[Tsuka]

>Si les mods sont bien pensés, et afin qu'ils ne s'entremêlent pas, je
>pense qu'ils utilisent chacun leurs propres tables pour gérer leurs
>données. Donc les risques de niquage de BDD sont minimes.

Ces mods là peut-être, mais pas tous ... genre ceux que j'ai rajouté recemment (confirmation visuelle ... demande de saisie du nom d'utilisateur ...) ont créés des nouveaux champs dans des tables existantes.

Catox > merci pour ton retour sur l'install des MODs en question bien sur je sais qu'on peut toujours revenir à l'ancienne version script ^^ c'est juste les eventuels changements dans la base qui me font donc un peu peur (mais je suis aussi un peu parano & pas forcément très à l'aise avec tout ça, le code c'est pas mon dada ... sachant qu'il m'est impossible de faire une backup de la bdd avant une manip, je ne peux m'en remettre qu'a celles de mon hebergeur, i.e. si ça plante on revient au mieux à la nuit dernière au niveau des messages).

[Catox]

ben en fait, ce mod a plusieurs façon de fonctionner.
en l'occurence, moi je l'ai testé en mode cookies.
en gros y a 5 étapes, la première est obligatoire, la deuxième nécessaire si le mod "machin-truc" n'est pas installé, la troisième et la quatrième dans je sais plus quels cas (notament si "machin-truc est installé") et la 5ème permet d'utiliser les bdd plutôt que les cookies... ce qui est pratique pour un utilisateur qui bouge, j'imagine, mais qui peut ralentir un peu le bidule, j'imagine encore ^^
--edit--
donc en simple : pas de modif de bdd paranoïante

sinon, pour les histoires de sessions, c'est un truc que j'ai encore du mal à cerner.
(pourquoi attendre la fin d'une session pour enregistrer ces paramètres de toute façon ?)

[Klaim]

Ben si t'attends pas la fin de la session pour enregistrer, alors tu enregistre à chaque appel de page. Donc la session n'as plus d'interet.

(kessta du mal a cerner avec les sessions? c'est des données sur le serveur, de la même façon que les cookies sont des données sur le client; la plus grosse différence vient du fait qu'on peut stocker plus et plus complexe que pour le cookie)

[Catox]

ce que j'ai du mal à cerner doit surtout se situer dans ce dont vous parlez.
Ma compréhention des sessions, c'est les variables qu'on veut pas voir transiter tout le temps du client au serveur mais qui sont, heu, volatiles... qui n'existent plus une fois la session en question terminée... donc au bout d'un certain temps ou d'une fin de session provoquée. (login par exemple)

Mais là, il s'agit de données qui doivent persister, qu'on doit de toute façon enregistrer dans un cookie, ou dans la bdd. Or si (ou puisque) la fin d'une session ne peut pas nécessairement déclencher un évennement, il faut bien sauvegarder ces données à un moment ou à un autre... donc tout le temps : je lis un topic, je le marque lu (ou plutôt je le "dé-marque" non-lu)

[Klaim]

Ben sois on demande a l'utilisateur d'indiquer sa fin de session effectivement, soit on enregistre tout le temps.
Dans tous les cas je trouve ça un peut lourd.

Le cookie c'est pas pratique si, comme beaucoup ici, l'utilisateur d'utilise pas qu'une machine pour accéder au forum.

[Catox]

> Dans tous les cas je trouve ça un peut lourd.

plus lourd que de devoir chercher les nouveaux messages à la main ? ^^

[Klaim]

Ben techniquement, oui.

[jem]

Hmm, mais les données qu'on peut mettre dans les cookies sont limitées, non ?
Potentiellement, le nombre de threads non lu est égal au nombre de threads total (soit plusieurs milliers).
Donc je me demande si ca ne va pas poser de problème.

[TRANTKAT]

... Z'ai mal à ma têêêête...

[Klaim]

Jem> non ils sont pas ilimités les cookies; mais me souviens plus des limites. Déjà tu peux faire que du varaible=valeur; en session tu peux avoir des tableau etc des structures plus complexes.
Enfin dans tous les cas en cookie c'est pas gérable poru la raison que j'ai dite au dessus. En session c'est bon mais ya le problème de find e session. Mettre tout directment dans la base c'est démultiplier les données traitées et donc alourdir le système. Au fond ils ont mis la solution la plus efficace autant techniquement que du point de vue de l'utilisateur.

Trantkat> Un pt'it r'montant pour oublier tout ça? Allé Beber, sert lui un verre!

[Catox]

pour le "techniquement plus lourd", la methode aux cookies ne l'est pas vraiment... pour la méthode mysql, le programmeur du mod dit que normalement ça ralentit pas le forum plus que ça (je tradusi ça par "le nombre d'appels à la bdd n'est pas suffisament augmenté pour ralentir le forum de façon notable ou génante"), sauf cas de configuration du serveur particulier (en gros)

pour le nombre de cookies/messages non lus, apparament on peut régler je sais plus où le nombre maxi dans le source php. Je crois qu'il est basé sur 300 topics, ce qui n'est pas exactement rien... et de toute façon certainement mieux que de devoir essayer de lire ces 300 topics en une seule traite ^^

[Klaim]

C'est lourd pour le client dans ce cas.

[Catox]

quand je dis "ne ralentis pas le forum" je parle de son utilisation hein... sinon ça n'a pas de sens...
je sais pas moi, si ce mod posait des problèmes à ce niveau, je pense qu'il y aurait eu plus de commentaires disant "my users say the forum has speeded down !"... or je n'en n'ai vu qu'un seul sur les 15 première pages du topic du gars... alors ?

[jem]

Ben quand je suis rentré de vacances en Septembre j'avais 120 topics non-lus....

Et puis, perso je surfe au boulot et à la maison, donc sur au moins 2 machines, donc l'option Cookies je suis moyen pour.