1. Le dimanche 1 octobre 2006 à 16:19 :: NiKo

> Tout simplement parce que les navigateurs web et le protocole HTTP n'ont clairement pas été étudiés pour la production de contenu mais pour leur affichage.

Faux. C'est oublier un peu rapidement les méthodes POST, PUT et DELETE par ex.

C'est d'autant plus bealot que ce sont des spécifications W3C : www.w3.org/Protocols/rfc2...

2. Le dimanche 1 octobre 2006 à 17:48 :: Laurent - CyberSDF

@NiKo: Je n'ai pas parlé de transmission des contenus mais bien de leur production. Je t'accorde que la phrase est mal faite car "affichage" peu se rapporter à HTTP (et donc être réducteur) alors que je pensais surtout au navigateur...
Ce que je voulais illustrer dans cette phrase c'est que HTTP, étant un protocole de transport asynchrone non connecté, il ne doit clairement pas être utilisé pour de la production de contenu (uniquement pour sa transmission) et qu'un navigateur sert (à la base) à afficher le dit contenu et ce même si il peu en envoyer via la méthode POST (quant à PUT et DELETE... Hein... :-p ).

3. Le lundi 2 octobre 2006 à 11:43 :: karl

Pourquoi penses-tu que PUT et DELETE ne fonctionne pas ?
Quels sont les reproches que tu lui fais ?
As-tu lu Architecture du Web et quels sont les reproches que tu fais au document ?

Lorsque j'ai dit séparation applicatif versus contenu. C'est ce que je fais en ce moment qui est idiot. Le fait d'avoir à utiliser une interface pauvre pour l'édition avec une liste de smilies au dessus, alors que je pourrais en utilisant un éditeurs à interface riche créer avec un POST unique le commentaire et un PUT le mettre à jour.

4. Le lundi 2 octobre 2006 à 20:32 :: Laurent - CyberSDF

@Karl:
Je n'ai pas dit que PUT et DELETE ne fonctionnaient pas ; Je n'ai d'ailleurs rien dit à leurs sujet.
Si ces méthodes sont employées dans un cadre sécuritaire suffisant (ce qui, tu l'admettra, n'est pas à la portée du pékin moyen) elles peuvent rendre d'énormes services, mais je me pose encore la question de savoir si le jeu en vaut la chandelle (mais l'option de ce choix reste ouverte).

Quant à poster un commentaire sur ce billet via une interface riche en utilisant POST, pas de soucis (c'est déjà possible d'ailleurs), mais pour ce qui est de le mettre à jour via PUT heuu... Si dans l'idée ça semble sympa, pour l'application concrète j'émets quelques réserves quand même

Mais bon, avec nos discussions de geeks à propos de HTTP, on passe à côté du message que je voulais faire passer qui est en substance : pourquoi utiliser un navigateur pour produire et gérer le contenu d'un site web alors qu'une application dédiée pourrait le faire tout aussi bien (voir mieux) et SUTOUT beaucoup plus user-friendly.

5. Le lundi 2 octobre 2006 à 21:47 :: NiKo

> pourquoi utiliser un navigateur pour produire et gérer le contenu d'un site web alors qu'une application dédiée pourrait le faire tout aussi bien

Ben deja parce qu'à l'heure actuelle t'as pas beaucoup d'autres choix si tu veux faire de l'universel facilement portable et accessible (non, XUL n'est pas implémenté partout, Flash c'est difficilement accessible et Java heu.. non rien)

Mais je plussoie quand à dire que HTML, CSS et Javascript sont pour l'heure parfois limités qiand on veut faire certaines manip' - du moins ça oblige à deporter beaucoup de manipulations du coté du serveur.

Pour ma part je mise beaucoup sur XForms, par exemple, mais on a le temps de voir venir

6. Le lundi 2 octobre 2006 à 21:51 :: NiKo

Et puis on peut tout à fait cumuler application et navigateur ! Regarde GMail, Writely ou Spreadsheet : C'est quand même super utilisable, non ? J'ai vu des "applets" (comprendre clients lourds) vachement moins riches fonctionnellement...

7. Le mardi 3 octobre 2006 à 00:02 :: Laurent - CyberSDF

Oui je dois avouer que GMail, Writely ou Spreadsheet (surtout ces deux derniers) sont pas mal côté user-friendly ; Seulement tu perd ta connexion au mauvais moment ou tu n'as pas de connexion pendant X temps, tu fais comment ?
Mon rêve : un outil qui serait a la fois beau, simple, ergonomique, efficace, complet et qui fonctionne (aussi) en offline...

8. Le mardi 3 octobre 2006 à 06:17 :: karl

Les centaines de milliers de pages sont gérées avec HTTP. Elles sont toutes éditables avec Amaya ou tout client sachant faire du PUT, et elles sont identifiées en termes d'éditions, donc oui c'est possible.

Quand à éditer un commentaire par PUT, oui c'est possible. HTTP PUT dis "mets à jour cette resourece désigné par cette URI". Le serveur reçoit le PUT, le contenu et l'URI. HTTP ne définit en rien pour tous ses verbes ce que le serveur doit faire (créer un fichier, mettre à jour un fichier, envoyer une fusée sur la lune). Lorsque le serveur reçoit le PUT avec URI et contenu, rien n'empêche de mettre à jour une base de données par exemple.

HTTP GET URI1
ou URI1 est la ressource désignant le commentaire: un contenu X.

Edition du contenu X dans le logiciel

HTTP PUT contenu X a l'URI1


Cas concret:
bitworking.org/ le weblog de Joe Gregorio attribue une URI unique à chaque commentaire, qu'il est possible de rééditer.

9. Le mercredi 4 octobre 2006 à 07:51 :: karl

Allez je me fais un poil tatillon.

La nouvelle phrase
"Tout simplement parce que les navigateurs web n'ont clairement pas été étudiés pour la production de contenu mais pour leur affichage."

serait plus exact en disant
"Tout simplement parce que les navigateurs web n'ont clairement pas été implémentés correctement pour la production de contenu mais pour leur affichage. Le premier navigateur Web WorlWideWeb, renommé Nexus, était un outil auteur, ainsi que AOLPress et comme l'est toujours Amaya par exemple."

10. Le lundi 30 octobre 2006 à 14:23 :: nicolaslips

Isotools (www.isotools.com) edite depuis plusieurs années un logiciel "CMS" offline...