Voulez vous voir ce spoiler?
êtes vous sûr?
vraiment sûr?
Windows a détecté que vous ne devriez pas ouvrir ce spoiler, si vous souhaitez vraiment continuer, veuillez cliquer sur « spoiler ».
êtes vous sûr?
vraiment sûr?
allez, encore une fois pour me faire plaisir
non rien 
boulet.
Ce n’est pas un bug, c’est une fonctionnalité … et c’est voulu : stocker les sujets lus, c’est stocker leur historique, soit de la charge serveur en plus, donc non. Par contre, de la charge client, osef… 
(oui j’adhère pas)
Vous pensez que si je crée un Topic de suggestion de fonctionnalités pour le Forum ça sera bien vu ?
Je pensais à un bbcode où tu fournis deux URL d’image, l’une pour la version small de l’image, l’autre pour la version big.
A l’affichage l’image small serait affichée et il suffirait d’un clic dessus pour que le src de soit remplacée par l’URL de la version big (comme la fonctionnalité qui limite les tailles dans la balise
pour les images trop grosse).
Toi t’es comme DarKChAm :o
Raynor > ça va, il te reste plus que deux trois cours de SQL :ane:
Allez, ça y est, tout le monde fait mumuse avec le spoiler : Et c’est moi qui ai commencé 
(fierté inside)
Sans-Nom > Stocker les messages non lus est aussi une charge serveur, non ? Sachant que cette fonction existe déja, le lien couterait-il vraiment en serveur ?
Ban et outside :o
InSiderz : non. ça passe entièrement par cookie. Essaye en les supprimant, tu verras l’effet…
Car charger à chaque fois la liste des sujets/messages lus (sujets lus = messages lus, suffit de garder la date de dernière lecture et comparer avec la date du sujet/message) ça a un coût.
Ah, c’est comme ça que c’est géré ? J’aurais fait une liste du dernier post lu pour chaque Topic (une liste par utilisateur)
:na:
Stocker la date de lecture des sujet de tous les forumeurs, ça a un cout (et puis il faut bien le gérer pour éviter les bugs), c’est surement plus simple en cookies. Mais ça doit faire des gros cookies, il n’y a pas une limite?
RFC 2109 :[quote=« »]
6.3 Implementation Limits
Practical user agent implementations have limits on the number and
size of cookies that they can store. In general, user agents’ cookie
support should have no fixed limits. They should strive to store as
many frequently-used cookies as possible. Furthermore, general-use
user agents should provide each of the following minimum capabilities
individually, although not necessarily simultaneously:
* at least 300 cookies
* [b]at least 4096 bytes per cookie[/b] (as measured by the size of the
characters that comprise the cookie non-terminal in the syntax
description of the Set-Cookie header)
* [b]at least 20 cookies per unique host or domain name[/b]
User agents created for specific purposes or for limited-capacity
devices should provide at least 20 cookies of 4096 bytes, to ensure
that the user can interact with a session-based origin server.
The information in a Set-Cookie response header must be retained in
its entirety. If for some reason there is inadequate space to store
the cookie, it must be discarded, not truncated.
Applications should use as few and as small cookies as possible, and
they should cope gracefully with the loss of a cookie.
[/quote]
:jap:
20 cookies de 4 Ko ça fait déjà de la place, mais c’est envoyé dans le header à chaque fois, (je crois non?) alors ça peut devenir lourd.
et en même temps, je n’ai pas vu beaucoup d’info dans les cookies sur mon fx.
ah si, c’est forum_read et nf_message_lu
edit2: je les vois bien passer dans le hedaer avec live http header 
Edité le 05/06/2007 à 16:05
Pour un petit membre comme moi, mon Cookie nf_messages_lu fait déjà 397 octets (avec 20 entrées).
Bien entendu que c’est lourd! Et aucune compression du cookie, car compresser le cookie => décompresser le cookie…
Et ensuite, ben le cookie passe dans chaque requête HTTP, donc le navigateur encapsule, le serveur décapsule (mais c’est moins lent qu’en BDD, donc ça va)…
Mais ça ne bourrine pas le serveur mySQL… (alors qu’IPB supporte MSSQL & Oracle, des frais dans un vrai SGBD ça l’aurait mieux fait hein (je ne met pas pgSQL, car bien que robuste, il semble pas aussi performant… dommage :/)
[quote=Raynor]Ah, c’est comme ça que c’est géré ? J’aurais fait une liste du dernier post lu pour chaque Topic (une liste par utilisateur)
[/quote]
Parce que tu penses pas que c’est la même chose? post = id, date = timestamp.
MySQL supporte très bien la charge. Le but c’est de répartir la charge au maximum, il est aussi performant qu’Oracle si les requêtes sont bien réparties.
Ce qu’il lui manque, c’est plutôt les fonctionnalités, et ça, c’est parce qu’il est encore jeune.
[spoiler]
<?php cluclu forever ?>
[sql]SELECT * FROM cluclu[/sql][/spoiler]
Y’a que moi qui me pose des question quand à la coloration synthaxique ? :neutre:
Ps : le bouton « soiler » ne fonctionne plus, faut écrire les balises a la main
ouais mais, toi tu es Dieu :o
Et je l’ai mis dans les réclams. Mais bref, ça n’y était que pour le SQL avant.
Par contre, pas d’indentation dans le bbcode ('fin je teste)
<?php
if ($x) {
return $x;
}
?>
autre chose, y’a que chez moi que les notifications par mail ne fonctionnent pas ?
Chez moi elles fonctionnent mais je reçoit plusieurs mail d’avertissement pour un seul message posté
Edité le 05/06/2007 à 18:25