Bonjour faux rhum,
aujourd'hui, le web a évolué, et le monde de la console, s'il avance doucement, se fait distancer en terme d'utilisabilité.
Il reste toutefois à mes yeux nettement plus confortable d'utiliser mon tmux persistant, mais pour combien de temps ?
De façon générale, je crois que le besoin se fait sentir -en tout cas pour moi- d'un moyen de communication entre les applis persistantes et le terminal graphique depuis lequel je m'y connecte.
Mails
Usage
Je lis mes mails avec ssh (ou mosh)+tmux+mutt depuis n'importe où — j'utilise rarement imaps.
Problème
Je me suis récemment abonné à des listes de diffusion généralistes dont je lis avec intérêt de nombreuses contributions, mais malheureusement, nombreuses sont les pièces jointes indispensables à la compréhension des courriels (parfois des documents word, ou simplement un message formatté en HTML sans aucune raison valable, ou encore un PDF officiel fuité).
Je me vois bien jouer un rôle "éducatif" de temps en temps, mais je ne suis pas là pour rappeler la nétiquette sans arrêt non plus.
Pour lire ces pièces jointes, c'est toujours la croix et la bannière : un clic ne suffit pas, je dois télécharger le fichier sur la machine où je me trouve pour le visionner correctement (évidemment, le HTML est en général illisible avec w3m).
Souhait de solution
Je voudrais, lorsque je fais mon ssh depuis certaines machines bien configurées pour ça, que mutt se débrouille pour lancer la visionneuse PDF de mon ordinateur de bureau. Ou ouvre le fichier html avec tous ses jpg dans un navigateur…
Notifications
Je fais de l'IRC, avec ssh+tmux+irssi depuis n'importe où.
Là, ça serait simplement un petit confort supplémentaire que d'avoir des notifications. J'ai vu que cela existait, à l'aide de sockets locaux, ou de fichiers temporaires "pollés" depuis la machine qui affiche les notifications, mais ça ne me satisfait qu'à moitié : c'est un gros hack ☺
Une solution générale ?
De même que le "long polling" a permis de saturer les serveurs web et d'éviter un passage à un protocole plus intelligemment conçu que HTTP (par exemple XMPP), mosh permet aujourd'hui, sur certains réseaux IP qui se comportent bien, d'améliorer élégament l'expérience utilisateur en établissant une communication UDP entre le client et le serveur. Est-ce que ce genre d'extensions au protocole SSH est une piste à suivre ? Avez-vous d'autres idées ?
Merci d'avoir lu !
# ii
Posté par rakoo (site web personnel) . Évalué à 1.
ii ne serait-il pas pratique ? Un faux fichier dans ton systeme de fichier, mis a jour en live avec les messages du chan actuellement utilise.
Sans avoir teste,
devrait être intéressant.
A mon avis, HTTP est très bien conçu. Il est juste très mal utilisé. Quand tu utilises un protocole d’accès sans état a des documents pour échanger des messages dynamiquement entre deux machines dont le rôle de client ou de serveur est indépendant du protocole de transport, tu fais n'importe quoi. Ça marche, mais c'est n'importe quoi. Pour le coup, STOMP aurait au moins été plus simple pour faire une transition douce vers de l’échange de messages
[^] # Re: ii
Posté par feth . Évalué à 1.
Merci de cette proposition de solution pour IRC. Il y en a d'autres, mais à chaque fois, on invente une solution ad-hoc pour le besoin.
Je voudrais un système plus général, extensible à des applications tierces.
[^] # Re: ii
Posté par feth . Évalué à 1.
Hm, j'ai une idée : il y a une communication entre les applications console et le terminal qui les affiche (par exemple pour mettre en place le titre…). Ce canal de communication doit pouvoir être détourné !
# export DISPLAY
Posté par jigso . Évalué à 1.
Aprés faut avoir un serveur X sur le poste client, et tu peux lancer sur le serveur des applis graphiques avec affichage déporté (xpdf, xbiff, …)
[^] # Re: export DISPLAY
Posté par jigso . Évalué à 2.
Ah et si tu veux tunneler d'autres protocoles, ssh le fait aussi ( cf options -L et -R ). Mais là il te faut évidemment avoir les clients graphiques sur ta machine.
[^] # Re: export DISPLAY
Posté par feth . Évalué à 2.
Ça reste vraiment suboptimal de faire passer le protocole X dans du ssh, question latence. Et mon serveur ne devrait pas lancer d'applis graphique, il n'a pas la RAM pour ça.
Je trouverais bien plus jolie une solution qui transfèrerait le fichier dans /tmp sur la machine cible (dans le temps, zmodem faisait ça bien) avant de lancer l'application correspondante sur la machine cible toujours -ou alors, si c'est un fichier "seekeable", d'utiliser un système de fichiers type sshfs pour accéder à la donnée.
Ce qui m'intéresse, c'est surtout que ça soit simple à utiliser.
# dbus
Posté par niol (site web personnel) . Évalué à 2.
Je pense que la bonne manière de faire est de le faire avec dbus. Une recherche rapide m'a amené gabriel (un vieux prototype) : http://www.eldemonionegro.com/blog/archivos/2008/05/22/howto-to-intercomunicate-processes-in-differentremote-machines-through-dbus
Une autre implémentation avec un protocole simple inventé pour l'occasion : http://sanpi.homecomputing.fr/content/notification-irssi-over-ssh
A adapter pour mutt avec la commande à configurer sur arrivée d'un nouveau courriel.
[^] # Re: dbus
Posté par feth . Évalué à 2.
Ça me semble propre aussi, merci du lien
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.