Liste de partage de Grorico

En bref- 1400 textes numérisés du site Gallica seront transférés sur Wikisource, pour être relus et corrigés par ses contributeurs.

Xavier de la Porte, producteur de l’émission Place de la Toile sur France Culture, réalise chaque semaine une intéressante lecture d’un article de l’actualité dans le cadre de son émission. Désormais, vous la retrouverez toutes les semaines aussi sur InternetActu.net.

La lecture de la semaine, encore une fois, sera une chronique de Clive Thompson dans le dernier numéro du magazine américain Wired, car, encore une fois, cette chronique est tout à fait passionnante. Son titre n’est pas ce qu’elle a de mieux, mais il est suffisamment intriguant pour donner envie de poursuivre : “Avantage aux Cyborgs : pourquoi l’accès à une intelligence supérieure passe par l’amélioration des relations avec vos assistants numériques.” Je vous rassure, la suite est plus claire.

Clive Thompson commence par poser une question obsédante et désormais classique : “Qui, de l’homme ou de la machine, est le plus intelligent ?” En 1997, rappelle Thompson, Deep Blue, le superordinateur d’IBM, a fait nettement pencher la balance en faveur des robots en battant Garry Kasparov aux échecs. Deep Blue a gagné parce que les ordinateurs peuvent produire, à la vitesse de la lumière, des calculs presque infinis : ce dont les humains sont incapables. Ce fut le prima de la force brute, de la capacité à passer en revue des millions de mouvements possibles pour trouver les meilleurs. Ce n’est pas comme ça que les humains jouent aux échecs. Les Grands Maîtres, nous rappelle encore Thompson, s’appuient, pour choisir le bon mouvement, sur des stratégies et des intuitions fournies par des années d’expérience et d’étude. Les intelligences humaines et artificielles ne travaillent pas de la même manière, ce qui a donné à Kasparov une idée intrigante.
C’est là où le papier de Thompson commence à nous apprendre quelque chose (en tout cas à m’apprendre quelque chose). Quelle fut l’idée de Kasparov ? Et si, au lieu de faire s’affronter les humains et les machines, on les faisait travailler en équipe ? Kasaparov a donc créé ce qu’il a appelé les advanced chess, les “échecs avancés”, dans lesquels les joueurs sont assistés par un logiciel. Chaque compétiteur entre la position de ses pièces dans l’ordinateur et utilise les mouvements proposés par le programme pour faire ses choix.

En 2005, dans un tournoi en ligne où tout le monde pouvait concourir, certaines paires humain-machine étaient tout à fait étonnantes. Mais celle qui remporta le tournoi ne comptait aucun Grand Maître, ni aucun des superordinateurs présents dans la compétition. Ce fut une équipe d’amateurs d’une vingtaine d’années, assistés par des PC ordinaires et des applications bon marché qui l’emporta. De quoi ont-ils tiré leur supériorité ? La réponse apportée par Thompson commence à nous éclairer sur le sens de son titre. Leur supériorité est venue de leur aptitude à tirer le meilleur parti de l’aide que leur apportait l’ordinateur. Ils savaient mieux que les autres entrer leurs mouvements dans la machine, ils savaient mieux quand il fallait consulter le logiciel et quand il valait mieux ne pas suivre ses conseils. Comme Kasparov l’a dit ensuite, un être humain faible avec une machine peut se révéler meilleur qu’un être humain fort avec une machine si l’être humain faible a une meilleure méthode. En d’autres termes, selon Thompson, les entités les plus brillantes de notre planète ne sont ni les êtres humains les plus accomplis ni les machines les plus accomplies. Ce sont des gens à l’intelligence moyenne qui ont une aptitude particulière à mêler leur intelligence à celle de la machine.

Et pour Thompson, cela ressemble beaucoup à ce qui se passe dans nos vies. Aujourd’hui, nous sommes continuellement engagés dans des activités “cyborguiennes”. On utilise Google pour trouver une information, on va sur Twitter ou Facebook pour se tenir au courant de ce qui arrive aux gens qui nous intéressent, et d’autres choses encore.

Or, un grand débat oppose ceux qui adorent notre vie moderne et numérique à ceux qu’elle perturbe. D’après Thompson, l’exemple fourni par les échecs nous montre pourquoi il existe un tel fossé. Ceux qui sont excités par les technologies sont ceux qui ont optimisé leur méthode, ceux qui savent comment et quand on s’appuie sur l’intelligence de la machine. Ceux qui ont adapté leur profil Facebook, configuré leurs fils RSS, etc. Et même, plus important, ceux qui savent aussi quand il faut s’écarter de l’écran et ignorer le chant des distractions qui nous appellent en ligne. Le résultat, c’est qu’ils se sentent plus intelligents et plus concentrés. A l’inverse, ceux qui se sentent intimidés par la vie en ligne n’atteignent pas cet état délicieux. Ils ont l’impression qu’internet les trouble, qu’il les rend “bêtes” pour reprendre le mot de Nicholas Carr.

Or, et on ne peut que donner raison à Clive Thompson, on ne peut pas faire comme si l’âge des machines étaient en passe de s’achever. Il est certain que l’on va de plus en plus dépendre de l’assistance numérique pour penser et se socialiser. Et trouver le moyen d’intégrer l’intelligence de la machine à nos vies personnelles est le défi le plus important qui nous soit offert. Quand s’en remettre à la machine ? Quand se fier à soi-même ? Il n’y a pas, d’après Thompson, de réponse univoque, et il n’y en aura jamais. Il s’agit là, selon lui, d’une quête personnelle. Mais en aucun cas nous ne devons éluder la question tant les avantages cognitifs sont grands pour ceux qui savent le mieux penser avec la machine. Au final, dit Thompson, la vraie question est : “quelle sorte de cyborg voulez-vous être ?”

Cette chronique de Thompson est passionnante pour elle-même, mais elle l’est aussi, me semble-t-il, pour ce qu’elle ouvre comme pistes. Et notamment, pour une explication qu’elle peut apporter à la crainte d’une partie des élites, et des élites françaises en particulier, face à l’internet. Car si Thompson, à la suite de Kasparov, a raison, si une intelligence moyenne alliée à une bonne maîtrise de la machine renverse les hiérarchies au point de se révéler supérieure à des années de travail et d’accumulation de savoir ; si cette règle s’avère exacte dans d’autres disciplines que dans les échecs, alors quelle supériorité resterait à ceux qui savent, ceux que l’on considère comme très intelligents, mais qui vivent sans les machines, qui les craignent, les méprisent, et ne s’en servent pas ? Et s’il y avait, derrière les arguments des contempteurs d’internet, la manifestation de cette crainte, la crainte d’un monde dans lequel ils ne domineraient plus, d’un monde qui menacerait leur position. Ca n’est qu’une hypothèse, mais il faut avouer qu’elle est tentante.

Xavier de la Porte

L’émission du 2 avril 2010 était consacrée au thème de l’informatique de l’information et de la communication et recevait comme invité Pierre-Eric Mounier-Kuhn, historien au CNRS et à l’université Paris-Sorbonne et Antonio A. Casilli, sociologue et chercheur au Centre Edgar Morin. Une émission à réécouter en différé ou en podcast sur le site de Place de la Toile.

Les utilisateurs américains de Google qui recherchent un "moyen de se suicider" ou des informations sur des "pensées suicidaires" voient désormais s'afficher au sommet de leurs résultats de recherche un numéro d'urgence pour suicidaires.

Dans une étude publiée par HP intitulée « Prévoir le futur avec les médias sociaux » les chercheurs Sitaram Asur et Bernardo A. Huberman « démontrent comment le contenu des réseaux sociaux peut être utilisé pour prédire des évènements dans le monde ...

Il y a quelques jours, je vous présentais une fonctionnalité de Photoshop baptisée Content-Aware Fill, qui était capable de générer toute une partie d’une photo. Vraiment pratique ! Ensuite, certains d’entre vous m’ont informé qu’il existait un plugin faisant la même chose sous Gimp. Je l’ignorais et j’ai été très heureux de l’apprendre.

Mais c’était sans compter sur Antoine qui m’a envoyé une nouvelle vidéo de démo de Content-Aware Fill qui sera sans doute dans le prochain photoshop et qui fait des choses vraiment hallucinantes !!!

euh… poisson d’avril ? lol

[Source]

Alors que de nombreux auteurs de carnets s'étaient assuré du contrôle de leurs données en installant les logiciels nécessaires sur leur propre serveur, l'avènement du micro-blogging et la mode des flux de statuts a ramené tout le monde, geeks y compris, vers des silos : Facebook et Twitter, ou identi.ca pour les intégristes. La sortie de StatusNet 0.9 il y a quelques semaines pourrait bien changer la donne, grâce à son introduction de OStatus, un protocole ouvert et décentralisé permettant d'interagir avec les statuts d'utilisateurs postés sur des serveurs dans le monde entier. Désormais, héberger des pensées, liens et autres bribes sur son propre serveur, tout en continuant la conversation avec les utilisateurs hébergés sur d'autres serveurs, devient possible. OStatus permet de sortir des silos en autorisant une architecture décentralisée qui n'a plus grand chose à envier aux architectures centralisées actuelles.

Cerise sur le gâteau, mais qui pour moi n'a pas de prix: StatusNet 0.9 a levé cette ***** de limitation à 140c qui, depuis que Twitter a arrêté l'envoi des tweets par SMS dans nos contrées, n'a vraiment plus de raison d'être.

Pour citer Evan Prodromou, OStatus est bâti au dessus d'une pile de composants, formats d'échanges et protocoles de communication :

• Atom pour les flux;
• ActivityStreams pour décrire les activités sociales;
• PubSubHubbub (PuSH pour les intimes) pour les notifications en temps réel;
• Salmon pour la conversation;
• WebFinger pour décrire les services disponibles : les flux et les points d'entrée de PuSH et de Salmon;

Toutes les communications entre les serveurs utilisent HTTP, dans le cadre d'une "architecture orientée service", c'est à dire que l'on communique simplement avec des services en appelant l'URL de leur point d'entrée.

Tentative de présentation rapide de ces différents composants.

Des formats

Atom

Le format de base pour décrire des publications regroupées en collections, les flux. Je vous renvoie à mon article d'il y a quelques mois. Atom est extensible, c'est donc le format de base idéal sur lequel bâtir des flux que l'on enrichira d'autres informations.

Activity Streams

Activity Streams est une proposition de norme visant à définir un format pour décrire des activités. Une activité est une action réalisée par un auteur sur un objet. Activity Streams se présente comme une extension du format Atom, c'est à dire que les informations sur l'activité peuvent enrichir un flux Atom. Le format est développé et a déjà été adopté par quelques jeunes startups comme Facebook, Google, Microsoft, MySpace, on peut donc espérer qu'il aura un certain avenir.

Deux spécifications sont en cours de rédaction, l'une décrivant le format lui-même, l'autre proposant des IRI pour des types d'actions (marquer comme favori, apprécier, entrer en contact, rejoindre, publier, partager, étiqueter...) et de cibles (article, commentaire, endroit, etc) classiques.

Pour l'instant, ce protocole est essentiellement utilisé dans StatusNet pour les communications entre serveurs. Par exemple, si l'utilisateur toto du serveur toto.org décide de suivre titi du serveur titi.net, à la fin du processus, après les différents contrôles, le serveur toto.org enverra au point d'entrée du serveur titi.net une notification contenant un enregistrement d'activité:

 <?xml version="1.0" encoding="UTF-8"?>
 <feed xmlns="http://www.w3.org/2005/Atom" xmlns:activity="http://activitystrea.ms/spec/1.0/">
   <author>
     <name>toto</name>
     <uri>http://toto.org/toto</uri>
   </author>
   <entry>
     <id>follow:totoid:titiid:timestamp</id>
     <title>toto is following titi</title>
     <content type="html">toto is following titi</content>
     <activity:verb>http://activitystrea.ms/schema/1.0/follow</activity:verb>
     <activity:object>
       <activity:object-type>http://activitystrea.ms/schema/1.0/person</activity:object-type>
       <id>http://titi.net/titi</id>
     <activity:object>
   </entry>
 </feed>

Threading, géo-localisation...

StatusNet implémente également d'autres extensions du format Atom:

• Atom Threading pour lier des contenus entre eux au sein de fils, en permettant de définir, pour chaque entrée, deux séries de liens : les IRI des entrées auxquelles elle répond, et les IRI de ses réponses;
• GeoRSS permet elle d'ajouter des données géométriques et géographiques à un flux. Elle est utilisée ici pour donner les coordonnées, latitude et longitude, des différents objets (localisation habituelle de l'auteur, localisation spécifique de chaque entrée: <georss:point>45.5088375 -73.587809</georss:point>;
• Atom Média pour décrire des contenus multimédias;

Des protocoles

PubSubHubSub

Le protocole PubSubHubbub, ou PuSH utilise un concentrateur, ou hub pour permettre de notifier en temps réel d'évènements. Il implémente les concepts de PubSub et de WebHooks dont j'avais déjà parlé et que j'utilisais dans le projet Sixties (bibliothèque PHP pour jouer avec les fonctions PubSub d'un serveur XMPP).

Le mécanisme est le suivant:

• un service désirant publier des contenus crée des points d'entrée dans un concentrateur. Ce sont des URL permettant de s'abonner aux mises à jour des contenus;
• il rend publique la liste de ces points d'entrée. Par exemple via la balise <link rel="hub" ...> dans un flux Atom;
• les utilisateurs qui souhaitent être notifiés de la publication de nouveaux contenus dans le flux ont deux solutions : soit recharger le flux à intervalles réguliers (polling, comme le gamin sur la banquette arrière répétant inlassablement à quelle heure on arrive ?), soit s'abonner au Hub. Pour cela, il leur suffit d'envoyer une requête de souscription à l'adresse de son point d'entrée. Cette requête contient une URL de rappel;
• lorsqu'un évènement survient sur le serveur d'origine, il en informe le Hub. Celui-ci interroge alors éventuellement le serveur pour récupérer plus d'informations sur l'évènement, puis notifie l'ensemble des abonnés en postant le contenu aux URL de rappel associées à chaque abonnement.

L'ensemble des communications est réalisée en HTTP et utilise le format Atom.

StatusNet embarque son propre Hub, il n'est donc pas nécessaire de passer par des services tiers. Ainsi, pour être prévenu immédiatement de la publication d'un nouveau statut, il suffit d'envoyer une requête à l'adresse du hub contenu une URL à appeler. Pour être notifié de mes mises à jours sur identi.ca, un simple GET ressemblant à cela suffit : http://identi.ca/main/push/hub?hub.callback=http://www.toto.net/callback_url/&hub.topic=http://identi.ca/main/push/hub&hub.mode=subscribe (pour sécuriser la transaction, le protocole définit un mécanisme de challenge, d'échange de clés, etc, je n'entre pas dans les détails).

Salmon

Salmon vise à notifier un contenu que du contenu en rapport a été publié. Pour utiliser le protocole, un flux doit fournir l'URL d'un point d'entrée à appeler lorsqu'une réponse est publiée. On peut préciser deux URL, l'une pour les réponses (par exemple les commentaires), l'autre pour les références. Un flux pourra contenir ce type de liens:

 <feed xmlns='http://www.w3.org/2005/Atom'>
   (...)
   <link rel="http://salmon-protocol.org/ns/salmon-replies" href="http://example.org/all-replies-endpoint"/>
   <Link rel="http://salmon-protocol.org/ns/salmon-mention" href="https://example.com/mention-handler" />
   (...)
 </feed>

Lorsqu'un serveur publie une réponse à un contenu publié sur un autre serveur (commentaire sur un article ou réponse à un statut par exemple), le serveur crée une entrée Atom au format Atom Threading et la publie à l'URL fournie dans le flux d'origine, via une requête HTTP POST. Le serveur d'origine peut alors s'il le désire publier la réponse et notifier tous les abonnés via PuSH. La spécification de Salmon prévoit un mécanisme de signature pour lutter contre le spam et différentes autres protections. Le protocole permet ainsi à des commentaires de remonter le flux jusqu'à sa source, d'où la référence au saumon, pour être ensuite partagé avec tous les abonnés au contenu initial.

Salmon me semble particulièrement intéressant car il répond à au moins deux problématiques:

• la fragmentation des contenus produits par un utilisateurs: un utilisateur peut désormais héberger sur son propre serveur ses réponses à des contenus publiés partout sur le Net. Il en garde le contrôle;
• la fragmentation des discussions : de multiples références à un article dans d'autres articles sont remontées à la source et, pour peu qu'icelle joue le jeu, partagées avec tous les utilisateurs qui la suivent;

WebFinger

WebFinger part du constat que l'on est plus habitué, pour désigner une personne, à utiliser une adresse mail qu'une url. Ou du moins une adresse du type user@server. Malheureusement, à la différence des URL, les adresses mail ne permettent pas d'en savoir plus sur leur propriétaire, par exemple son identité, les adresses des services qu'il utilise, etc. Choses que permet une URI donnant accès par exemple à une page Web ou un profil FOAF.

WebFinger est donc un protocole permettant à partir d'une adresse de type user@server d'obtenir des méta-données sur l'utilisateur qu'elle désigne. Ces méta-données sont exprimées au format XRD. XRD est un vocabulaire créé par l'OASIS pour décrire toutes les méta-données de n'importe quelle ressource. Il est plus générique que FOAF, spécialisé dans la description des personnes et de leurs liens.

WebFinger s'appuie sur plusieurs autres protocoles en cours de discussion au sein de l'IETF:

• Defining Well-Known URIs propose de regrouper données de service d'un domaine dans un répertoire .well-known situé à la racine de ce domaine. Par exemple les fichiers destinés aux robots d'indexation, le plan du site, l'icône, etc;
• host-meta: Web Host Metadata propose que les méta-données d'un domaine soient stockées au format XRD dans un fichier host-meta à l'intérieur de ce dossier;
• LRDD: Link-based Resource Descriptor Discovery utilise un lien link pour référencer des méta-données sur un document. Ce lien peut être dans les entêtes HTTP d'une réponse à une requête, ou une balise LINK dans un document XML quelconque. Dans le cas des fichiers XRD de description d'un domaine, le lien pointera vers un template permettant d'obtenir des informations sur une ressource : par exemple <Link rel="lrdd" template="https://meta.example.org/?q={uri}" type="application/xrd+xml" />

Le mécanisme utilisé par WebFinger pour obtenir un profil à partir d'une adresse est le suivant:

1. transformer l'adresse mail en une XRI, un identifiant universel de ressource^[1]. Cela se fait simplement en la préfixant de acct: pour 'account'';
2. récupérer le fichier de description du domaine. Soit pour l'adresse acct:clochix@identi.ca le fichier https://identi.ca/.well-known/host-meta. On notera au passage que l'adresse mail n'a pas à exister. clochix@identi.ca n'est pas une adresse mail, mais l'identifiant de mon compte sur identi.ca;
3. rechercher dans ce fichier le lien de type lrrd possédant un template : <Link rel="lrdd" template="https://identi.ca/main/xrd?uri={uri}" />;
4. récupérer la description des données de l'utilisateur via ce template. On obtient un fichier XRD décrivant le profil de l'utilisateur.

En pratique

Google fournit ce type d'information pour tous les utilisateurs de Gmail :

• GET https://gmail.com/.well-known/host-meta
• on obtient le fichier suivant:

 <?xml version='1.0' encoding='UTF-8'?>
 <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'
      xmlns:hm='http://host-meta.net/xrd/1.0'>
   <hm:Host xmlns='http://host-meta.net/xrd/1.0'>gmail.com</hm:Host>
   <Link rel='lrdd' template='http://www.google.com/s2/webfinger/?q={uri}'>
     <Title>Resource Descriptor</Title>
   </Link>
 </XRD>

• on peut alors consulter le profil de l'adresse toto@gmail.com à l'URL http://www.google.com/s2/webfinger/?q=acct:toto@gmail.com. Soit, pour quelqu'un ayant un profil public et activé Buzz, quelque chose comme:

 <?xml version='1.0'?>
 <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
   <Subject>acct:toto@gmail.com</Subject>
   <Alias>http://www.google.com/profiles/toto</Alias>
   <Link rel='http://portablecontacts.net/spec/1.0' href='http://www-opensocial.googleusercontent.com/api/people/'/>
   <Link rel='http://webfinger.net/rel/profile-page' href='http://www.google.com/profiles/toto' type='text/html'/>
   <Link rel='http://microformats.org/profile/hcard' href='http://www.google.com/profiles/toto' type='text/html'/>
   <Link rel='http://gmpg.org/xfn/11' href='http://www.google.com/profiles/toto' type='text/html'/>
   <Link rel='http://specs.openid.net/auth/2.0/provider' href='http://www.google.com/profiles/toto'/>
   <Link rel='describedby' href='http://www.google.com/profiles/toto' type='text/html'/>
   <Link rel='describedby' href='http://s2.googleusercontent.com/webfinger/?q=acct%3Atoto%40gmail.com&amp;fmt=foaf' type='application/rdf+xml'/>
   <Link rel='http://schemas.google.com/g/2010#updates-from' href='http://buzz.googleapis.com/feeds/123456789012345678901/public/posted' type='application/atom+xml'/>
 </XRD>

Ce qui rappelle au passage que Google est fournisseur OpenID. Le fichier contient également les liens vers le profil Google, dont les informations sont disponibles dans plusieurs formats, y compris FOAF et des micro-formats comme hCard et XFN, et le flux des mises à jour de Buzz.

Le même fichier est disponible sur toute installation de StatusNet 0.9. Par exemple, la description de mon compte sur identi.ca:

 http://identi.ca/main/xrd?uri=acct:clochix@identi.ca
 <XRD>
   <Subject>acct:clochix@identi.ca</Subject>
   <Alias>http://identi.ca/user/82435</Alias>
   <Link rel="http://webfinger.net/rel/profile-page" type="text/html" href="http://identi.ca/user/82435"/>
   <Link rel="http://schemas.google.com/g/2010#updates-from" type="application/atom+xml" href="http://identi.ca/api/statuses/user_timeline/82435.atom"/>
   <Link rel="http://microformats.org/profile/hcard" type="text/html" href="http://identi.ca/clochix/hcard"/>
   <Link rel="http://gmpg.org/xfn/11" type="text/html" href="http://identi.ca/user/82435"/>
   <Link rel="describedby" type="application/rdf+xml" href="http://identi.ca/clochix/foaf"/>
   <Link rel="http://salmon-protocol.org/ns/salmon-replies" href="http://identi.ca/main/salmon/user/82435"/>
   <Link rel="http://salmon-protocol.org/ns/salmon-mention" href="http://identi.ca/main/salmon/user/82435"/>
   <Link rel="http://ostatus.org/schema/1.0/subscribe" template="http://identi.ca/main/ostatussub?profile={uri}"/>
 </XRD>

On trouve ici les liens vers mon profil, encore une fois disponible à plusieurs formats, ma timeline, les points d'entrées pour Salmon et pour s'abonner à mes mises à jour via OStatus.

OStatus

OStatus s'appuie sur les précédents protocoles pour définir un format d'échange entre des serveurs.

Les statuts

Chaque statut correspond à une activité au format Activity Streams, donc à une entrée Atom. L'action retenue est la publication (post) d'un objet qui peut être une note, c'est à dire un court billet ne contenant qu'un corps (à la différence d'un article qui contient lui également un titre et un résumé), un statut ou un commentaire. Notes et statuts sont similaires, la différence est sémantique, le contenu d'un statut se rapportant à son auteur quant une note peut traiter de n'importe quel sujet.

Un statut peut être lié à :

• d'autres contenus auxquels il répond, via Atom Threading s'il constitue une réponse : <thr:in-reply-to ref="http://identi.ca/notice/1" href="http://identi.ca/notice/1"></thr:in-reply-to>
• des personnes : <link rel="ostatus:attention" href="http://server/user"/> lorsque je m'adresse à quelqu'un;
• d'autres statuts s'il fait partie d'une conversation: <link rel="ostatus:conversation" href="http://server/conversation/1"/>

Les flux

L'activité d'un utilisateur est regroupée au sein de flux Atom. Chaque flux doit posséder un point d'entrée PuSH fournissant l'URL où s'abonner à ses mises à jour. Il peut également fournir des point d'entrée Salmon où être notifié des réponses et des mentions.

Par exemple, voici un extrait du flux d'Evan Prodromou, le créateur de StatusNet :

 <?xml version="1.0" encoding="UTF-8"?>
 <feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom">
   <id>http://evan.status.net/api/statuses/user_timeline/1.atom</id>
   <title>evan timeline</title>
   <author>
     <name>evan</name>
     <uri>http://evan.status.net/user/1</uri>
   </author>
   <link href="http://evan.status.net/" rel="alternate" type="text/html"/>
   <link href="http://evan.status.net/main/push/hub" rel="hub"/>
   <link href="http://evan.status.net/main/salmon/user/1" rel="http://salmon-protocol.org/ns/salmon-replies"/>
   <link href="http://evan.status.net/main/salmon/user/1" rel="http://salmon-protocol.org/ns/salmon-mention"/>
   <link href="http://evan.status.net/api/statuses/user_timeline/1.atom" rel="self" type="application/atom+xml"/>
   (...)

Les communications

Les communications entre les serveurs utilisent WebFinger pour découvrir les adresses des flux des utilisateurs, PuSH et Salmon pour échanger des messages.

Lorsqu'un utilisateur publie un nouveau statut, son serveur notifie l'ensemble des abonnés de la mise à jour via PuSH.

Les serveurs recourent à Salmon pour échanger entre eux des évènements concernant leurs utilisateurs:

• lorsqu'un utilisateur publie un contenu à l'attention d'un autre utilisateur (en utilisant par exemple la syntaxe @toto qui se traduira par un link rel="ostatus:attention" dans le flux), son serveur envoie une notification au serveur du destinataire via le point d'entrée Salmon;
• idem pour les réponses;
• lorsqu'un utilisateur s'abonne ou se désabonne aux mises à jour d'un autre utilisateur, rejoint ou quitte un groupe, ajoute le statut d'un autre utilisateur à ses favoris ou le re-publie, son serveur notifie de même le serveur de l'utilisateur ou du groupe concerné.

Ouf ! Le repas était copieux, il va falloir un peu de temps pour assembler les pièces du puzzle et digérer tout ça. Mais je suis pour la première fois depuis longtemps optimiste en ce qui concerne les silos de données : bien sûr OStatus n'attaquera pas la suprématie de Facebooke et Twitter, mais pour qui souhaite reprendre la main sur ses flux, une solution existe à présent qui me semble crédible, ou en passe de le devenir. Ne reste plus qu'à attendre que Facebook et Twitter implémentent OStatus pour permettre au monde libre de dialoguer avec leurs prisonniers. Vont-ils le faire ?

Techniquement, mais clairement, Benjamin Sonntag explique les différences entre l'internet mobile et l'internet. "Doit-on espérer un jour voir venir une "appellation d’origine contrôlée" pour le terme "Internet", qui imposerait aux opérateurs de respecter les bases de ce qui a fait l’innovation dans le réseau : une adresse IP pour chaque client, une absence de filtrage par protocole ?", telles sont les intéressantes perspectives que lance l'auteur..

 Bookmark this on Delicious - Saved by hubertguillaud to infrastructures neutralitedunet mobilite internetactu internetactu2net internet - More about this bookmark

Bonjour, Le but de ce sondage est d'évaluer, parmi les pratiques agiles, celles dont les personnes tirent le plus de bénéfices. N'hésitez pas à commenter votre vote et à proposer votre classement détaillé....

Ce midi, on va apprendre a s’installer un petit serveur proxy rapidement et sans avoir besoin de serveur dédié… Simplement en utilisant Google App Engine qui offre un espace de stockage gratuit.

Ce proxy est basé sur le code Mirrorr et a été porté par Amit Argawal sur Google App Engine. Il permet entre autre la consultation de vidéos flash (Youtube and co). J’ai repris cette technique décrite initialement pour Windows et j’ai essayé de la rendre compréhensible à la fois pour Windows, Mac mais aussi Linux.

Le première étape consiste à vous créer un compte sur Google Apps.

Cliquez sur le bouton « Create an application » et nommez votre application. Attention, si vous mettez « proxy » dans le nom, sachez que celui-ci peut être détecté par certains filtres donc banni.

Une fois que c’est fait, rendez vous sur le site de Python.org et téléchargez puis installez Python (Pour Linux, Windows ou Mac) ou faites un

sudo apt-get install python

Rendez vous ensuite sur la page de téléchargement du SDK Google app engine pour Python et téléchargez la version qui correspond à votre OS. Dézippez ou installez là. Téléchargez ensuite le fameux proxy en Pyhon et décompressez le quelques part sur votre ordinateur.

Lancez ensuite l’outil Google App Engine. Sous Windows ou Mac, c’est super simple car ça se fait via l’interface. Une fois lancée, faites un clic droit et sélectionnez « Add Existing ».

Dans Path, mettez le chemin d’accès vers les fichiers décompressés du Proxy et en port, laissez 8080.

Editez ensuite la ligne pour changer l’APP_ID par le votre (moi c’est korbenproxy)

Sauvegardez et cliquez sur Deploy (le bouton bleu en haut à droite) pour balancer votre application proxy en python sur les serveurs de Google.

Si vous êtes sous Linux, éditez le fichier app.yaml dans le répertoire qui contient les fichiers du proxy.zip et remplacez YOUR_APP_ID par l’ID de votre application (moi c’est toujours korbenproxy). Placez vous ensuite dans le répertoire du SDK google pour Python et lancez la commande suivante (en changeant l’email et le chemin d’accès bien sur) :

./appcfg.py --no_cookies --email=korbenfake@korben.info --passin update /home/korben/proxy/

Et voilà, le tour est joué ! Rendez vous ensuite sur l’url de votre Google App Engine comme par exemple : http://korbenproxy.appspot.com/

Faites en bon usage !

Amit a aussi mis en ligne une petite vidéo résumant tout ça. Ça vous aidera peut être à mieux comprendre certaines parties.

Et accessoirement, vous venez d’apprendre à déployer une application Python sur Google App Engine ! Elle est pas belle la vie ?

Enfin, si vous avez la flemme de faire tout ça, je vous recommande de vous inscrire à la mailing list Circumvator qui enverra chaque jour dans votre boite mail, de nouvelles URL de proxys.

[source]