En même temps l'intérêt d'un commentaire c'est avant tout d'être lu. Je suis perfectionniste, j'aime bien corriger la petite faute qui traînait, mais si ça veut dire que je suis le seul à pouvoir lire mes commentaires, je ne vois pas trop l'intérêt.
L'intéret c'est de répondre à ce besoin :
C'est largement insuffisant pour mon usage personnel. Quand j'ai publié un commentaire je ne reste pas à le relire en boucle (et ça ne serait pas très efficace, voir ci-dessus). Je suis content de moi, je fais un changement de contexte, je vais lire mes mails, et je reviens 10/20 minutes après.
Maintenant si ton besoin, c'est de pouvoir éditer un commentaire après coup suite aux réponses des autres participants, ben dis-le de suite, plutôt que de te cacher derrière une raison fallacieuse. Parce que là je ne suis pas d'accord avec toi. Quand tu dis des mots avec ta bouche, une fois que les mots sont dits, ils sont dits. Si il y a malentendu, tu t'expliques, tu ne peux pas "enlever" les mots qui ont été dits. La sur linuxfr, c'est pareil. A toi d'assumer tes propos et de les expliquer si besoin, ou de t'excuser si tu blesses quelqu'un.
Encore de l'optimisation prématurée ! Pourquoi se soucier à implémenter ce genre de choses tant que le brouillon n'est pas une charge sur le site ? C'est du temps perdu dans le vent, un utilisateur humain (si c'est un bot, hein, ce n'est pas le nombre de brouillons mais le nombre d'action par seconde qu'il faut limiter) ne va pas créer assez de brouillons dans toute sa vie pour imposer une charge assez importante au site...
1/ Qu'n sais-tu ?
2/ On voit bien que ce n'est pas toi qui aura à gérer les conséquences
3/ Si tu ne mets pas de limite, tu trouveras toujours quelqu'un qui abusera et détournera le système. Puis de toute façon, mette un brouillon et l'envoyer 6 mois après, ça n'a pas de sens non ? alors pourquoi le garder ? Mettre une limite sur ce genre de choses me parait une bonne idée, d'autant plus que j'ai parfois tendance à être néglgent sur ce genre de détails.
Le nouveau serveur LinuxFR a 2To de disque dur vive (source). Donc si tous les utilisateurs passaient 10 heures par jour 350 jours par an à rédiger des brouillons inutiles, il faudrait un peu plus 23 an avant de surcharger le serveur actuel. On a de la marge !
On s'en fout, c'est comme ça qu'on se retrouve avec des applis Java qui assent 90% a traverser des couches et des surcouches pour aller récupérer et afficher une info située dans une table de BDD. C'est marrant de voir des communautés où les gens, dans un contexte de programmation, sont les premiers à dire "fait du profiling avant d'optimiser de faux bottlenecks" se mettre à concevoir des règles sur un site web et tout concevoir à l'outrance, augmenter la complexité sans aucun gain ou demander aux codeurs de prévoir la collision d'un astéroïde...
Je crois que je vais laisser tomber toute discussion avec toi : tu sembles complètement hermétique à tout autre point de vue que le tien, Tu as juste envie de faire un caprice.
[^] # Re: ouha-ou
Posté par totof2000 . En réponse au journal L'édition des commentaires sur LinuxFR, ou pas ?. Évalué à 6.
En même temps l'intérêt d'un commentaire c'est avant tout d'être lu. Je suis perfectionniste, j'aime bien corriger la petite faute qui traînait, mais si ça veut dire que je suis le seul à pouvoir lire mes commentaires, je ne vois pas trop l'intérêt.
L'intéret c'est de répondre à ce besoin :
C'est largement insuffisant pour mon usage personnel. Quand j'ai publié un commentaire je ne reste pas à le relire en boucle (et ça ne serait pas très efficace, voir ci-dessus). Je suis content de moi, je fais un changement de contexte, je vais lire mes mails, et je reviens 10/20 minutes après.
Maintenant si ton besoin, c'est de pouvoir éditer un commentaire après coup suite aux réponses des autres participants, ben dis-le de suite, plutôt que de te cacher derrière une raison fallacieuse. Parce que là je ne suis pas d'accord avec toi. Quand tu dis des mots avec ta bouche, une fois que les mots sont dits, ils sont dits. Si il y a malentendu, tu t'expliques, tu ne peux pas "enlever" les mots qui ont été dits. La sur linuxfr, c'est pareil. A toi d'assumer tes propos et de les expliquer si besoin, ou de t'excuser si tu blesses quelqu'un.
Encore de l'optimisation prématurée ! Pourquoi se soucier à implémenter ce genre de choses tant que le brouillon n'est pas une charge sur le site ? C'est du temps perdu dans le vent, un utilisateur humain (si c'est un bot, hein, ce n'est pas le nombre de brouillons mais le nombre d'action par seconde qu'il faut limiter) ne va pas créer assez de brouillons dans toute sa vie pour imposer une charge assez importante au site...
1/ Qu'n sais-tu ?
2/ On voit bien que ce n'est pas toi qui aura à gérer les conséquences
3/ Si tu ne mets pas de limite, tu trouveras toujours quelqu'un qui abusera et détournera le système. Puis de toute façon, mette un brouillon et l'envoyer 6 mois après, ça n'a pas de sens non ? alors pourquoi le garder ? Mettre une limite sur ce genre de choses me parait une bonne idée, d'autant plus que j'ai parfois tendance à être néglgent sur ce genre de détails.
Le nouveau serveur LinuxFR a 2To de disque dur vive (source). Donc si tous les utilisateurs passaient 10 heures par jour 350 jours par an à rédiger des brouillons inutiles, il faudrait un peu plus 23 an avant de surcharger le serveur actuel. On a de la marge !
On s'en fout, c'est comme ça qu'on se retrouve avec des applis Java qui assent 90% a traverser des couches et des surcouches pour aller récupérer et afficher une info située dans une table de BDD.
C'est marrant de voir des communautés où les gens, dans un contexte de programmation, sont les premiers à dire "fait du profiling avant d'optimiser de faux bottlenecks" se mettre à concevoir des règles sur un site web et tout concevoir à l'outrance, augmenter la complexité sans aucun gain ou demander aux codeurs de prévoir la collision d'un astéroïde...
Je crois que je vais laisser tomber toute discussion avec toi : tu sembles complètement hermétique à tout autre point de vue que le tien, Tu as juste envie de faire un caprice.