BFG a écrit 904 commentaires

Parce que pour une messagerie instantanée, les messages sont beaucoup plus courts et nombreux, ce qui donnerait lieu à des niveaux d'indentation abyssaux, totalement illisible ? Et parce qu'une messagerie instantanée se rapproche beaucoup plus de l'oral, donc les participants ont bien le contexte en tête, rendant inutile ce genre de moyens ?

Vous n'avez rien compris à mon message et à ceux du fil de discussion (en particulier ceux qui parlent de NNTP), je vous invite à les relire jusqu'à ce que vous ayez compris.

Bizarre, moi je vois souvent que dès que quelqu'un est dans deux conversation, ça fait souvent des réponses de travers, sans compter quand quelqu'un post deux messages différent (même dans la même conversation) proche l'un de l'autre.

Comme quoi, les expériences diffèrent. Peut-être ignorez-vous que dans nombre de clients IRC, il est possible de taper les premières lettres du pseudo, puis d'appuyer sur la touche tab du clavier, pour que le pseudo soit complété automatiquement, ce qui fait que l'on peut en quelque sorte adresser un message à une personne en particulier avec un moindre effort.
De plus, le cerveau a une fonction de mémoire, ce qui fait qu'en lisant un message, on peut aisément savoir à quoi il fait référence, et ce, sans même avoir besoin de suivre une indentation visuelle, déplacer son curseur ou quoi que ce soit d'autre.

Mauvais coincoin, changer de coincoin. Pycc faisait un affichage par thread si tu préfère.

Que de complications, alors que cela marche parfaitement sans.

Ça commence à appairaître dans les clients XMPP.

Un exemple ?

Vous imaginez un chat de groupe sans norloge

heu ? C'est une plaisanterie ? J'ai déjà une horloge, là, dans un coin de l'écran.

Les moules de la tribune pensent qu'il est indispensable de faire référence à un message de manière très précise chaque fois qu'elles parlent, alors qu'on peut constater que cela fait des générations que des conversations croisées fonctionnent très bien sur n'importe quel canal IRC.
Ces "norloges" permettent également de voir quelles sont les réponses à un message, et cela de manière parfaitement illisible au survol du curseur.

Encore aujourd'hui, telles des génies incomprises, elles sont fières de leur invention, mais ça finira bien par disparaitre, tout comme les adorateurs du Minitel (cocorico, linuxFR !).

Je garde espoir qu'un jour tu comprendras que HTTP est un protocole de transport, et que le comparer a des protocoles applicatifs n'a pas de sens.

C'est un protocole pour faire des requêtes, unidirectionnel et sans état. Les cookies pour simuler un état sont un bricolage, et WebSocket pour supporter la bidirectionnalité est une ignominie.
IP est un protocole de transport, HTTP n'est qu'un protocole applicatif qui est inadapté à presque tout ce pour quoi il est actuellement vendu.

HTTP est justement tellement souple que tu peux faire un paquet de trucs avec

Quand on a un marteau, tout ressemble à un clou.

Ainsi que l'état dans lequel elle se restaure. Quand bien même elle sauvegarderait sa "session" (des choses à implémenter en plus, alors que si l'application n'était pas quittée sans raison par le système, cette fonction n'aurait même pas à être implémentée), on peut avoir envie de démarrer une session vide soi-même.

Ici.

Édition : en fait, le bug est corrigé, je ne sais pas comment ont fait les autres personnes.

Comme par exemple flashplugin ?

Depuis quand le r est la troisième lettre de "change" ("change directory", voir chdir(2)) ?

Avec zsh :

typeset -m "XDG*"

Là où ça se complique, c'est pour envoyer un mail chiffré à Mmme Michu. Déjà, la probabilité que Mme perde sa clé privée tend vers 1 avec le temps (Mme Michu et les sauvegardes…). Je vois pas trop comment faire sans passer par un tiers… une idée ?

Même en local, la clef privée est chiffrée symétriquement par un mot de passe. On pourrait donc imaginer la stocker chez un tiers. Malheureusement, GPG ne permet pas la Confidentialité_Persistante : dès que l'on réussit à avoir la clef privée en clair, on peut tout déchiffrer.

Il ne s'agit pas juste de décider si les 2 hachages (ou images) ont l'air de se ressembler, il s'agit de savoir si ils sont identiques. Voir également http://www.thc.org/papers/ffp.html.

Pour le déménagement, je ne sais pas, mais ils la remettent à zéro quand on change des options de son forfait, entre autres, et aussi ne font des offres intéressantes que pour attirer de nouveaux abonnés, car ces offres ne peuvent pas être attribuées aux personnes déjà abonnées.

et surtout on n'a aucun respect pour ses clients historiques

C'est exactement la même chose chez les autres opérateurs.

Si, mais cela diminue profondément son intérêt.
C'est un peu comme si chaque fournisseur d'email ne permettait de communiquer qu'avec les autres utilisateurs de ce même fournisseur. C'est trop local. Le fait que ça utilise XMPP n'est qu'un "détail d'implémentation". Ils auraient aussi bien pu inventer leur propre protocole et en publier les spécifications que ça n'aurait fait presque aucune différence.

On est, et on cherche à être compatibles entre nous au sujet de nouvelles fonctionnalités (celle qui me vient principalement en tête est le microblogage); et pour ce on s'appuie sur des XEP qui sont en cour d'élaboration, et qui ne sont donc pas encore des standards (Celle ci pour ceux que ça intéresse). La standardisation et donc la compatibilité entre client est un point important que nous ne voulons pas perdre.

Mes excuses, je ne savais pas (faute d'intéressement et d'utilisation), c'était donc un mauvais exemple. J'aurais pu parler des différentes solutions de surveillance de serveurs basées sur XMPP, mais hélas, je n'en sais pas plus non plus, peut-être qu'également il y a concertation entre celles-ci pour que des standards de supervisions basés sur XMPP émergent.

Ainsi que la messagerie Microsoft, et celle d'Apple. Je pense qu'il ne veut pas le(s) compter car il n'y a pas la fédération. Facebook et le reste du monde ne sont pas dans la même composante connexe bien qu'ils utilisent tous les deux XMPP.

Oui, je suis d'accord. D'un autre côté, vu qu'à 95% l'usage est le même (rechercher - lire - répondre - citer), c'est idiot de gaspiller autant de ressources en MySQL - PHP - Apache - javascript - navigateur Web juste pour les 5% restants. Pas tant d'un point de vue économique ou écologique que dans une optique d'a-centralisation d'Internet (avec une ligne ADSL et un modem-routeur en ARM je peux faire tourner un node NNTP, pas un forum phpBB).

On constate tout de même des évolutions, par exemple XMPP, qui s'est fait une place tout seul, et évolue grâce aux XEP.

Il est aussi intéressant de voir qu'XMPP a donné lieu à d'autres protocoles par son extensibilité et sa qualité.

Cependant, ces protocoles dérivés restent des protocoles dédiés à un programme, et non à une tâche. Salut à Toi et Jappix sont deux protocoles dérivés d'XMPP, mais ils ne sont (à ma connaissance extrêmement limitée) compatibles entre eux du point de vue des fonctionnalités relatives au réseau social. Peut-être un jour verra-t-on une une plus grande standardisation entre ces deux (ce n'est qu'un exemple).

XMPP commence à servir de socle à de nouveaux protocoles, peut-être semble-t-il avoir une certaine flexibilité, comme HTTP et HTML/etc. en a une, qui a conduit à ce qu'il soit utilisé pour tout et n'importe quoi, même quand c'est sous-optimal. Certains se décarcassent à faire évoluer HTTP et HTML en ajoutant SPDY/WebSockets, la vidéo, WebGL, le stockage hors-ligne, la géolocalisation, etc. mais c'est signe qu'on manque d'un certain nombre de protocoles plus adaptés, et surcharger HTTP/HTML uniquement pour cette raison est une erreur.

Si XMPP commence vraiment à prendre plus d'ampleur, c'est bien, mais il ne faudrait pas faire la même erreur que la sur-utilisation d'HTTP.

Merci, c'est intéressant. De cet algorithme, je ne connaissais que l'utilisation "prendre un élément aléatoire dans une liste dont on ne connait pas la taille à l'avance et sans tout stocker".

Et bien il faut la générer quand même cette liste, et c'est en O(n), à moins que vous ne preniez comme hypothèse de départ que la liste existe et qu'elle est déjà triée, mais avec ce genre d'hypothèses on peut résoudre un certains nombre de problèmes facilement en O(1).

Je suis preneur quand même.

en:Dutch_national_flag_problem

Je suis capable de trier n + 1 nombres distincts compris entre 0 et n + 1 en O(1), moi! :)

En O(n), je vois, mais en O(1), je voudrais bien voir votre algorithme.

En le générant ainsi, vos nombres auront peut-être une mauvaise distribution aléatoire. Il faudrait tester avec un outil comme ent.

J'avais prévenu qu'il était un peu trop distrayant, mais on peut en faire abstraction si l'on veut. Si par contre, on a décidé qu'il serait "illisible", "fouillis", alors je ne vois rien à répondre.
Les passages techniques sur les modifications de bits nécessitent de toute façon un crayon et un papier, cela vous dérange tant que ça ? Si vous ne les comprenez pas ou ne voulez pas essayer, alors acceptez la conclusion que ce n'est pas pour vous et qu'il faut vous en tenir aux protocoles existants.

le souci c'est que ça pète les liens de la newsletter (bon osef , elle n'existe plus iirc) et des flux rss iirc.

Quid de <base href=...> ?

Remplacer https://linuxfr.org par http://linuxfr.org devrait suffire (venant de https ça reste en https ; venant de http ça reste en https).

Uniquement pour les inscrits, et par le biais d'une redirection qui est faite en HTTP simple (qui annule temporairement le chiffrement).