Hello,
Ce journal m'a fait avoir une idée.
Serait-il possible d'implémenter un "résolveur" d'url courtes ?
Je n'ai jamais fais joujou avec Ruby, alors je propose cette idée, si quelqu'un à le courage de l'implémenter avant que je ne me mette à coder avec ruby …
Bref, voilà le tout: je pense qu'on pourrait utiliser (par exemple) unshort.me
Il suffirait d'ajouter une méthode process_short_links au fichier suivant
Je décroche sur la regexp pour filtrer les liens:
SL_LINK_REGEXP = RUBY_VERSION.starts_with?('1.8') ? ….
Faut aussi se faire le taff de lister et valider les services qui sont supportés.
Par exemple, pour unshort.me, voila ce qu'ils indiquent sur leur site:
Unshort.me has been tested and works with the following URL shorting services:
bit.ly
TinyURL
tr.im
cli.gs
Ow.ly
Snurl
kl.am
POPrl
Idek.net
budURL
is.gd
even with Hapylink :)
and expected to work with other services too.
J'imagine que ca se base sur la lecture de l'entête http au moment de la redirection.
Après, il faut juste récupérer le json qui va bien, et construire l'attribut title qu'on met dans la balise du lien en question
Le résultat serait donc le lien orignal avec l'attribut title contenant la vrai url.
Cela permettrait de voir avant de cliquer…
Qu'en pensez-vous ?
Quel impact sur le temps de chargement / perf du site ?
# hum...
Posté par s[e]th & h[o]lth (site web personnel) . Évalué à 1 (+0/-0).
Très honnêtement, je voudrais bien participer mais je n'ai rien compris.
# Humm...
Posté par Bruno Michel (site web personnel) . Évalué à 2 (+0/-0).
L'intérêt m'échappe mais si quelqu'un veut proposer le patch, c'est un peu plus compliqué que ce qui est dit dans le journal. La regexp en question ne sert que pour les liens internes vers le wiki, comme
[[[wiki]]]. La transformation de la syntaxe wiki[]()en lien se fait dans la bibliothèque redcarpet qui elle-même la bibliothèque en C upskirt.[^] # Re: Humm...
Posté par Bruno Michel (site web personnel) . Évalué à 2 (+0/-0).
Et aussi, unshort.me est un logiciel propriétaire, il faudrait trouver un équivalent libre (ou le coder).
[^] # Re: Humm...
Posté par fyah . Évalué à 5 (+0/-0).
tout simplement connaitre l'url de destination avant de cliquer sur le lien
[^] # Re: Humm...
Posté par Arthur Geek (site web personnel) . Évalué à 2 (+0/-0).
J'ai failli te faire un coup de lemonparty ou de goatse avec bit.ly pour te donner un indice...
Prochainement, je vous proposerai peut-être un commentaire constructif.
[^] # Re: Humm...
Posté par Xavier Teyssier (site web personnel) . Évalué à 3 (+0/-0).
L'intérêt est double :
1. On connait d'avance le lien sur lequel on va cliquer (ce qui permet éventuellement de savoir si on l'a déjà lu !).
2. Cela permettra au lien de toujours fonctionner le jour où le service de rétrécissement d'URL sera en plein DoS, voire aura disparu.
[^] # Re: Humm...
Posté par fyah . Évalué à 1 (+0/-0).
C'est une des questions que je me suis posé par rapport à la performance: il serait effectivement intéressant de garder l'information de résolution quelque part ... mais du coup comment on procède ? il faudrait presque créer une table de correspondance qui contiendrais tous les liens déjà traduits, comme ça on garde effectivement le vrai lien et on ne dépend plus du bon vouloir du service en question.
[^] # Re: Humm...
Posté par Xavier Teyssier (site web personnel) . Évalué à 5 (+0/-0).
Je serais encore plus violent : à la soumission de la dépèche/journal/Forum/etc, tous les miniliens connus seraient transformés en lien normaux.
[^] # Re: Humm...
Posté par Paul . Évalué à 4 (+0/-0).
On peut commencer par déconseiller fortement les miniliens aux rédacteurs ?
# Nettoyage de printemps
Posté par Bruno Michel (site web personnel) . Évalué à 3 (+0/-0).
Entrée de suivi ouverte en 2011 avec moins de 10 votes => je ferme.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.