Commentaires sur : Transfert ou transport ?

Par : Le propre du transfert et le tranfert du propre (infrastructure studies)

Le propre du transfert et le tranfert du propre (infrastructure studies) — Wed, 26 Oct 2011 08:56:50 +0000

[...] que d’infrastructures de transports.Quelle distinction fais-je entre transport et transfert (Cf Transfert ou Transport en 2009)?Tout d’abord, et l’on me pardonnera d’évacuer si grossièrement la [...]

Par : karl

karl — Fri, 04 Dec 2009 03:19:54 +0000

Et pour avancer un peu plus dans le contrôle de la totalité de l’infrastructure.
http://code.google.com/intl/fr/speed/public-dns/docs/using.html

Par : Damien B

Damien B — Mon, 30 Nov 2009 19:52:47 +0000

N’est pas dans le sens où je n’ai jamais vu « Internet » en tant que couche

Par : Olivier G.

Olivier G. — Mon, 30 Nov 2009 15:27:44 +0000

Tiens, j’ai pour ma part envie d’aller voir du côté de la physique et plus particulièrement de la thermodynamique : « à où les protocoles de transports transportent des données, les protocoles applicatifs transfèrent des représentations. »

On peut rapprocher ça du transfert de chaleur entre deux matériaux, ou du transport de chaleur entre deux lieux. Encore une dichotomie transport d’information/transport de matière (le transfert de chaleur se fait sans intermédiaire matériel, le transport de chaleur nécessite un caloporteur — l’eau des radiateurs par exemple).

Par : Christian

Christian — Mon, 30 Nov 2009 15:05:30 +0000

> Christian : intéressant ce modèle en couche, qui n’est pas le modèle OSI, d’où est-il issu ?
N’est-ce pas ? Je l’utilise pour simplifier, mais bien sûr il est faux

Par : jadlat

jadlat — Mon, 30 Nov 2009 10:24:36 +0000

on postule aussi le transfert de compétences – je ne sais pas ce que cela donnerait du transport de compétences ?

Par : Damien B

Damien B — Mon, 30 Nov 2009 09:54:46 +0000

Christian : intéressant ce modèle en couche, qui n’est pas le modèle OSI, d’où est-il issu ?

Aurélien : GData est construit sur le protocole et le format (mais la base est peu importante, vu que c’est pratiquement inutilisable sans un client dédié, c’est donc juste une facilité d’écriture du middleware), et GData ne permet d’accéder qu’à une minuscule partie des données stockées chez Google : les données publiques des services hébergés (de plus en plus restreint, cf. l’impossibilité de chercher les calendriers publics) et les données « privées » auxquelles le login donne accès. Au final, ça ne fait pas bezéf, comparé au trois dépôts de donnés principaux de Google (web indexé, Gmail et Deja). Et Google Wave en protocole serveur vise l’interopérabilité entre les serveurs… Wave. De même que NNTP assurait l’interopérabilité entre les serveurs News et IRCsp entre les serveurs IRC et CARP entre les serveurs de Cache. Bref, Wave ne rentre pas en ligne de compte dans cette discussion

Par : Aurélien

Aurélien — Sun, 29 Nov 2009 13:36:32 +0000

> »L’interopérabilité avec les autres serveurs n’est presque pas un objectif à term [...]
Pour Google, le transfert n’est pas important ou plutôt il est si peu mis en pratique »

Oui et non, google wave, le protocol pas l’interface vise l’intéropérabilité entre serveur.
Et Gdata l’API qui permet de manipuler une bonne partie des données stockées chez Google est construite sur Atom, le protocol la aussi et pas le format. Donc si ce n’est pas mis en pratique c’est notre faute pas celle de Google.

Par : Christian

Christian — Sat, 28 Nov 2009 20:58:21 +0000

Je crois que ce qu’écrit Karl est très juste. Je crois aussi que cela va dans le sens de ton dernier billet sur SPDY, Yves-marie.
La compétition économique amène Google à consolider et à re-construire une architecture Client/Serveur distribuée en maîtrisant le client, les protocoles de transport, et bien sûr les serveurs. Google construit son WebFrame.

Par : karl

karl — Sat, 28 Nov 2009 20:15:08 +0000

REST est un style architectural qui est encore une couche au dessus de HTTP.
Je rejoins Christian dans son analyse. Chacun des domaines est d’ailleurs interprété en fonction de la culture propre des intervenants. Lorsque l’on SPDY de Google qui est une forme d’extension à HTTP. Ils ne s’intéressent proprement dit qu’à l’efficacité du transport et pratiquement pas à l’amélioration du transfert.

Google centralise tous les services dans une même coquille. Sa seule interaction au final n’est avec qu’avec les logiciels clients. L’interopérabilité avec les autres serveurs n’est presque pas un objectif à terme. Ils ont besoin de rapidité, ils ont des besoins spécifiques qu’ils maîtrisent au cœur de leurs applications. Lorsqu’on a créé un écosystème avec un fort contrôle sur tous les éléments du système, on peut se permettre d’imposer sa loi à l’écosystème. Microsoft l’a fait dans l’univers de la bureautique. Google le fait petit à petit pour le Web. Nous n’y sommes pas encore bien sûr.

Pour Google, le transfert n’est pas important ou plutôt il est si peu mis en pratique (quid de HTTP PUT, DELETE, etc., des mime types et des headers) sur le Web aujourd’hui, que Google peut se concentrer sur ce qui améliore le transport des données.