Goffi a écrit 1537 commentaires

C'est aussi le nom d'un client XMPP qui n'est pas trop vilain d'ailleurs. Font pas trop dans l'originalité…

j'ai oublié de répondre. Ici on publie sur DLFP, sur une agrégation de blogs, on publie sur son propre blog. Je pense que la différence est importante (surtout que même sans la redirection, on sait qui lit quoi rien qu'avec les logs du serveur web sur DLFP). Dans mon flux, j'ai tous les billets, et j'aimerais bien qu'on ne sache pas lesquels j'ai ouvert en particulier.

Bon de toute façon ça a été changé, merci à l'équipe de planet-libre.

C'était l'utilisation à la base, ce n'est plus utile depuis que ce site intègre son propre raccourcisseur et compte les urls pour un nombre fixe de caractères quelle que soit la taille de celle-ci.

ah je ne savais pas ça, n'utilisant pas le site en question. Je ne comprends donc vraiment pas l'intérêt de ces trucs (sauf à la limite dans le cas d'IRC avec une URL beaucoup trop longue).

Si le but, c'est de pouvoir le mettre sur des affiches, ça va poser problème quand les gens vont devoir taper ☃ ou ␲ dans la barre d'URL.

Oui enfin si c'est pour avoir un truc facile à taper, autant utiliser la vraie URL. Parce 7xcEfs12 c'est pas super facile à taper non plus sans faire d'erreur, ni à retenir. À la limite sur une affiche les codes QR sont plus adaptés.

Je l'attendais celle là :)

À ma connaissance, les raccourcisseurs sont surtout utilisés sur un machin limité à 140 caractères et non octets, ou dans des système de messagerie sans hyperlien, le tout étant déjà en unicode. Le seul « intérêt » (à part pour les receleurs d'informations personnelles) c'est d'avoir un truc visuellement plus court, indépendamment du nombres d'octets utilisés en sous-main.

une approche naïve pourrait déjà être de lister les suites de caractères les plus utilisées, et des les associer à un caractère unicode. Par exemple je vois dans l'adresse de mon commentaire linux, fr, .org, nodes, comments, modifier qu'on pourrait associer à un caractère unicode.

Outre que je trouve aussi ces raccourcisseurs d'url ridicules, je me demande s'il ne serait pas possible, quite à faire ça, de les compresser de manière bijective, en utilisant par exemple unicode (à supposer que l'url de base ne soit pas internationalisée). Au moins ça rendrait la chose dépendante d'un algorithme et non d'un site, et ça éviterait le traçage… Bon évidemment ça veut dire que le client implémente l'algorithme, vu que ça ne marcherait plus en cliquant simplement sur le lien.

me demande si ça a été tenté tiens.

on trouvait. la version python de PhantomJS n'est plus maintenu depuis longtemps à priori…

une des réponses (la mieux notée) passe par selenium. Je n'ai pas testé mais gageons que ça reste d'actualité.

bon de toute façon dans l'idéal nos tests vont devoir passer su Gecko et Webkit, donc si l'API est compatible (ce qui à peu près le cas mais pas à 100% de ce que j'ai lu), je vais faire en sorte de pouvoir utiliser phantomJS et SlimerJS.

en tout cas merci, c'est bien utile ce genre de projet.

Je crois que tu bosses sur SlimerJS justement non ? Est-ce qu'il y a des facilités pour l'utiliser en Python ? Il n'est pas encore headless apparemment, la FAQ indique comment se passer de xorg, mais quid des dépendances ? Elles sont nombreuses ?

En fait je vais avoir besoin d'un projet du style pour les tests automatisés de mon projet, et pour le moment PhantomJS me parait plus intéressant notamment parce qu'il est headless (et qu'on trouve facilement comment l'utiliser avec Python).

je n'ai pas dit qu'il l'avait aboli, Badinter tout ça 1981 je connais quand même, mais de mémoire il a ou il a eu l'intention de l'inscrire dans la constitution pour rendre impossible ou au moins très difficile de la rétablir.

il y a inscrit l'abolition de la peine de mort non ?

Ce n'est pas PGP lui même qui est obsolète, c'est l'utilisation de PGP avec XMPP, cf XEP-0027.

Bravo pour cette version, c'est un projet actif et c'est impressionnant de voir le nombre de modules.

2 petites questions:

• est-ce que vous allez maintenir une version python 2 (éventuellement sous la forme d'un code utilisable sous python 2 et 3) ? Dans le cas contraire, quand estimez vous la fin du support python 2 ?

• est-ce que browser2 est utilisable en dehors de weboob ? Pour un projet d'une fois qui ne mérite pas une inclusion sous forme de module ?

Oui je pense aussi que c'est plutôt l'absence de MAM (la 0313) qui pose problème, mais j'aurais voulu avoir confirmation

Oui tout à fait:

• https://twistedmatrix.com/trac/wiki/TwistedMail

• https://twistedmatrix.com/documents/current/_downloads/emailserver.tac

• http://pepijndevos.nl/twsited-smtp-server-with-authentication/index.html

OTR n'a rien à voir avec XMPP, c'est un bricolage de l'utiliser avec, dont l'intérêt principal est à mon sens est d'être utilisable avec les passerelles (c.-à-d. quand on sort de XMPP). Ce n'est certainement pas la méthode qui va être standardisée (pas plus que PGP qui était un usage historique maintenant obsolète). Le journal est d'ailleurs faux sur ce point.

La méthode propre passe par jingle et est en cours de travail: http://xmpp.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-02.html . Il y aussi quelques XEPs par ci par là mais je ne les connais pas encore, je ne sais pas ce qu'elle valent (XEP-0200 par exemple).

OTR est censé être utilisé sur l'instant, comme un journaliste parlerait à une de ses source: sur le moment il sait à qui il parle, mais après coup on ne peut plus le prouver. Ça n'est pas fait pour laisser des messages hors ligne, ni même pour quoi que ce soit d'autre que de la discussion instantanée (pas de mise en forme, pas d'état de discussion, pas de correction de message, etc. Les clients qui font de la mise en forme font aussi un bricolage, ça devient du bricolage par dessus du bricolage).

Déja XMPP, avec son multi-ressoureces non synchronisées sur la même adresse foutait le bazar mais là c'est le ponpon, en plus les messages recus sont illisibles.

ça veut dire quoi multi resources non synchronisées sur la même adresse ? Le sysème de resources de XMPP fonctionne très bien, quel est ton problème au juste ?

@inlineCallbacks rend l'écriture de code Twisted plus aisé, mais ce n'est pas utilisé pour tout et ça reste un peu du bricolage dans Twisted.

l'inconvénient principal des inlineCallbacks est une perte de performances énorme dans pypy (de ce que j'en ai lu, je n'utilise pas -encore ?- pypy).

Pour l'écriture et le débogage, l'écriture est en effet un peu difficile, c'est une habitude à prendre, par contre pour le débogage je n'ai pas trop de soucis, surtout grâce à leur système qui permet de tracer l'origine d'un Deferred en mode debug.

Bon en tout cas faut voir les évolutions de tout ça, mais si ça peut effectivement interagir comme promis, l'avenir devrait être très intéressant.

Tu vois là l'(un des) intérêt(s) d'une ligne éditoriale. Le système de notation et d'étiquettes ou encore les moteurs de recherche te donnent une certaines vue des choses, une ligne éditoriale en est une autre, subjective. Rien ne t'empèche de te faire ta propre sélection d'articles et de la mettre (ou les mettre si les articles sont redistribuables) sur un site public, voire d'associer ça avec d'autres.

En fait c'est une réflexion intéressante, peut-être que le journal est un peu confus par contre. Les articles ne sont pas « oubliés » (on peut les retrouver dans les archives), mais peu mis en valeur et ils disparaissent rapidement sous d'autres journaux/dépêches ou après « l'effet buzz ».

Il y a de toute façon un certain consumérisme de l'information qui explose depuis quelques années (surtout avec des choses comme Twitter). Ce qu'il faudrait, c'est ralentir la cadence; reste à savoir de quelle manière. Une sélection d'articles sur un site à part, me semble une piste.

Bon ben super. Reste à voir si mon blog rentre dans le cadre (a priori je pense, mais comme je parle surtout d'un logiciel, pas sûr que ça passe), mais je n'ai plus trop de raison de râler. Merci :)

Il y a eu des changements ?

Ah apparemment les liens vers l'article complet pour les derniers articles ne pointent plus sur planet-libre, c'était le point le plus bloquant pour moi. Tu confirmes que c'est bien que ça qui a été changé ?

Merci en tout cas, c'est appréciable de voir que les critiques sont écoutées :)

Avec pendatactyl la barre d'url n'est pas visible non plus (enfin ça se remets avec :toolbarshow Navigation Toolbar), et à l'usage c'est très pratique. Mais bon là ça triche un peu, l'url est dans la barre de statut, et il suffit d'appuyer sur o pour ouvrir une autre, ou O pour modifier celle courante.

peu importe (j'ai un exim avec à peu de choses près le conf de base, c'est possible que ça soit limité *), ce que j'indique c'est qu'avec le courrier SMTP s'il y a un élément limitant dans la chaîne t'es marron. Je viens de tomber sur ça par exemple: http://www.outlook-apps.com/maximum-email-size/

Le tableau indique que des MUA (ici outlook et windows live mail, il n'y en a pas pour Thunderbird) imposent des limites, et tous les serveurs cités en imposent aussi, sauf si ça passe par un service externe.

* en effet ça semble être limité à 50 Mio, mais de toute façon la limite de gmail étant apparemment 25 Mio, mon MTA n'a pas été concerné.

Okay, donc avec XMPP aussi, si je comprends bien, ça marche dans un cas idéal, à savoir le cas où l'expéditeur et le récepteur sont connectés au même moment.

Euh non, ça marche dans le cas normal, et si jamais tu as un quota sur le serveur de fichiers, tu peux passer par un autre, ou faire un envoi P2P, qui est aussi un cas normal mais qui demande à ce que l'autre soit en ligne.

2 personnes en ligne en même temps c'est beaucoup moins rare que de te retrouver dans un cas où tout le monde gère sa propre chaîne de courriel, et que tout soit configuré sans limite.

Base64 : ça dépend du MUA (si son auteur a décidé de forcer à encoder en base64) car ça doit faire 15 ans que les MTA sont capables de passer du 8-bits sans accroc.

ok pour le coup de la taille, si toute la chaîne accepte du 8 bits ça fonctionne.

Stockage intermédiaire : si tu n'es pas dans le cas idéal en XMPP, il faut bien que ça soit stocké sur un serveur. Donc même raison pour mettre des quotas qu'en SMTP.

Oui il faut que ça soit stocké, mais une seule fois, pas à chaque MTA.

Reprise de transfert : bien, mais ça implique que les serveurs stockent pendant un certain délai les morceaux de fichiers dont le transfert est inachevé. Devrait influer négativement sur les quotas.

Les quotas tu es dépendant du serveur de fichiers que tu choisis. En SMTP tu es dépendant de tes MUA/MTA que tu peux maîtriser, mais aussi de ceux de ton correspondant.

Si Thunderbird stocke les gros fichiers sur des services externes et envoi le lien dans le message, c'est qu'il y a une raison…

Si je suis mon propre MTA/MDA et que mon destinataire est son propre MTA/MDA, il n'y a pas d'intermédiaire imposant ses propres règles non plus, quelle est la différence ?

Oui c'est sûr, si t'as un cas idéal où tout le monde laisse tout passer, et si t'acceptes tout le bordel qui va avec (base64, stockage du fichier à chaque étape, transfert à recommencer depuis le debut si ça foire, et y'en a sûrement d'autres que j'ai pas en tête), ça peut marchoter. Mais en pratique ça n'arrive pas, j'ai eu le cas hier avec le fichier de ~ 70 Mio qu'on a essayé de m'envoyer depuis un compte gmail, et comme déjà dit je gère mes propres serveurs, c'est pas de mon côté que ça coinçait (enfin j'ai pas vérifié, mais a priori je n'ai rien mis dans ma conf pour bloquer quoi que ce soit).

Avec XMPP le fichier passe par un canal dédié, peut être stocké ailleurs que le reste du message, y'a pas d'augmentation de taille, et même si y'a un quota au milieu tu peux toujours faire un P2P. Et je passe tous les autres problèmes de SMTP.

Je ne dis pas que XMPP est un protocole parfait, il a ses défauts, mais je dis qu'il est un excellent candidat pour remplacer SMTP, et probablement le meilleur candidat actuel.

Je dis que les pièces jointes sont un bricolage par dessus SMTP (qui est MIME), et que SMTP n'étant pas adapté au transfert de fichiers, on a de nombreux problèmes avec à cause de ça.

La taille des pièces jointes n'est effectivement pas limitée par SMTP ou MIME je n'ai jamais dis le contraire, mais l'architecture du réseau, son historique, le fait que les messages soient stockés par chaque MTA fait qu'en pratique c'est limité, soit au niveau du MUA, soit d'un MTA.

Et le protocol est tout à fait lié à ces limites, outre son historique, le fait que les messages soient stockées par les MTA, et que la taille des fichiers soit beaucoup augmentée à cause de base64 fait qu'en pratique on limite les tailles à des valeurs ridicules de nos jours.

XMPP envoit le fichier par un canal séparé, rendant ces limites inutiles. Il est toujours possible de mettre des quotas, ça personne n'a dit le contraire, mais rien n'empêche que si je m'auto-héberge on m'envoit un fichier de 3 Go. Essaye de faire pareil avec juste du SMTP. En plus de ça, XMPP gère le P2P, et la plus question de quota.

P.-S.: ohhh un nouveau dessin, c'est lié au nombre de commentaires dans un fil ? Rigolo :)

Qui a parlé de limite de taille dans MIME ?