OK je vois que certaines choses ne sont pas claires dans l'esprit de tout le monde, donc:
Arsene a écrit :
Les limites ne sont pas technologiques, elles sont industrielles. La fibre optique nous libérera sous peu des problèmes de volumes de transactions.
Ce n'est pas parce que les connexions sont/seront meilleures qu'il faut gâcher de la bande passante avec des protocoles non adaptés. En résumé: l'optimisation c'est bien, mangez-en.
Arsene a écrit :
Quant à HTML il est évident que c'est un langage bien trop faible pour les besoins à venir. XMPP est-il beaucoup plus puissant, c'est probable si on considère que c'est un langage d'échange plus qu'un langage de description. Couvre-t'il pour autant l'ensemble des besoins des prochaines années ? Pas si sûr.
Très mauvaise comparaison,
XMPP n'est pas un langage mais un protocole.
Arsene a écrit :
Pas sûr non plus qu'il faille absolument un "langage central fédérateur" : ce point de vue me semble aujourd'hui obsolète. Je crois qu'on va plutôt vers des langages spécialisés par tâches et que tout l'enjeu est dans la capacité de dialogue qu'ils entretiendront entre eux.
Interrogation pertinente. Personnellement j'aurais tendance à penser que le langage fédérateur c'est XML, et le protocole fédérateur XMPP. Les deux étant extensibles ils offrent de nombreuses possibilités.
QuentinC a écrit :
Vous m'intriguez de plus en plus avec votre XMPP (quand je dis vous, c'est en particulier changacco mais pas uniquement).
Je croyais pourtant que c'était « seulement » le pendant de MSN du côté du libre, c'est-à-dire un simple protocole de messagerie instantanée... je vais largement faire dévier le sujet initial avec cette question, mais en quoi XMPP peut ou pourrait supplanter (X)HTML, HTTP et le web ?
XMPP-Core est un protocole de streaming XML,
XMPP-IM utilise XMPP-Core pour faire de la messagerie instantanée,
les XEP (XMPP Extension Protocols) définissent d'autres protocoles également basés sur XMPP mais pas (encore) publiés en tant que RFC, ces extensions n'ont pas forcément quelque chose à voir avec la messagerie instantanée.
XMPP n'a pas vocation à remplacer (X)HTML pour la raison expliquée plus haut.
Pour ce qui est de HTTP, XMPP a des avantages comparé à HTTP, il offre une authentification universelle, permet les connexions persistantes simplement, a une série d'extensions pour le transfert de flux binaires tels que la vidéo et l'audio, a une série d'extensions permettant l'abonnement simple à un nœud, etc.
Maintenant je vais nuancer un peu mes propos, XMPP est la standardisation d'un protocole originellement prévu pour la messagerie instantanée, de très bonnes extensions (les fameuses XEP) ont été produites au fil des années mais aucune refonte ni majeure ni mineure n'a été effectué sur le protocole de base. Je suis une des très rares personnes qui pensent (et apparemment une des très rares personnes à y avoir pensé tout court) qu'une refonte de ce protocole qui a quelques années maintenant pourrait être une bonne chose car s'il y a un truc que je déteste avec le web actuel c'est le blocage par la rétro-compatibilité, XMPP n'étant pas encore utilisé pour le web, je pense qu'une refonte avant de se lancer pourrait être bénéfique. Je réfléchis actuellement sur ce sujet et si j'estime que j'arrive à quelque chose d'intéressant je partagerai sur les Mailing Lists adéquates. Tout ça pour dire que oui, XMPP c'est bien, mais comme tout ce n'est pas parfait et peut-être que ça n'est pas tout à fait près pour le grand public.
QuentinC a écrit :
Sinon pour la notion de document, je suis assez d'accord avec Nod. Un document reste pour moi quelque chose d'assez statique, et dès le moment où il y a des parties de la page qui changent, c'est un début d'application. Par contre il faut s'entendre sur le terme « statique » : une page qui présenterait les cours de la bourse et qui serait actualisé en temps réel à condition d'appuyer sur F5 reste un document, malgré que son contenu change régulièrement à la demande. Par contre, ça devient une application si la mise à jour est automatique en temps réel sans avoir quelque chose à faire, par exemple via AJAX.
De mon point de vue tout document est sujet à modification donc dans un système qui permettrait la notification
simple du lecteur en cas de mise à jour, pourquoi s'en priver ?
