Ben non, ça serait pareil. On se mettrait d'accord sur une API commune, on aurait une VM qui lancerait des petites applications 'volatiles', avec des droits limités, comme le font déjà les navigateurs Web. Sauf que maintenant on leur demande, et de faire tourner des applications en JS, et de gérer des plugins tiers, et d'avoir un rendu qui va bien, et de faire gaffe à la sécurité sur tout ça, et de le faire le plus vite possible.
Tu veux dire une interface en (qt/gtk/cocoa/windows) pour chaque site ? Avec la logique métiers coté serveur en un langage (comme aujourd'hui) et coté client en un autre langage ?
Et à chaque modif de ton site, il faut mettre à jour tout les clients ?
Maintenir une compatibilité pour chacun des à peu prêt 20 OS présent (avec les téléphones qui représente une part non négligeable des visites) ?
Toi, tu va relancer les métiers du web :)
Aujourd'hui, si ton client possède une navigateur web récent, roule ma loutre, c'est bon.
Ça serait vraiment plus propre d'utiliser un protocole dédié à chacun de ces types d'application (XMPP ou IRC pour le clavardage en direct, RTSP pour la vidéo, pourquoi pas une extension de NNTP pour gérer le plussage/moinssage sur les forums).
Déjà, premier problème, le réseau. HTTP, c'est du "non connecté". Tu envois ta requette, le serveur repond, ok merci bye. Il y a des petits mecanisme en plus pour faire du keep-alive, mais l'idée est la. Donc, niveau sécurité et ouverture de flux, c'est simple. Tu ouvre le 80 dans un sens, et roule ma loutre. Si tu rajoute tout un tas de protocol avec tout un tas de port dans tout un tas de direction, déjà, pour le nat/pat, c'est foutu et ensuite pour la sécurité réseau, c'est un peu plus poilu (mais on s'en fou, je te l'accorde).
fiable, codée en dur, optimisée pour l'usage auquel elle est destinée, sécurisée car elle sait ce qu'elle devra gérer et sait ce qu'elle ne devra pas gérer
Si tu sais faire ça pour 20 OS, tu dois être riche ou sous payé :)
Quand tu tombes sur des sites Web qui te disent "Viendez sur notre IRC" en te proposant une application javascript, et que tu dois fouiller pour trouver le nom du serveur et du canal, afin de les donner à ton client IRC, celui-la même qui ne pose pas trop de problèmes de sécurité, car il ne parle que l'IRC et n'a pas à interpréter un code non connu à l'avance comme c'est le cas avec du JS, tu te dis que y'a quelque chose de pourri au royaume du Web.
J'aurais plus confiance en la sécurité d'un client xml/javascript qu'en un client (autre que les grosses pointures connu) IRC. Le site web qui fait de l'IRC va juste envoyer les messages au client et recevoir les messages du client. Le client n'interprète rien (à part les styles, les smiley et autre conneries) et de plus personne ne peut connaitre son adresse IP (à part le serveur).
Mais bon, je te dis pas que tu à tord ou que j'ai raison, c'est une question de point de vue.
Écrire un chat (par exemple) pour la vingtaine d'OS sur le marché ou un équivalent en web.
Avec le couple tomcat/java/postgres coté serveur, XML entre le client et le serveur et javascript/html coté client,je pense que j'aurais fini en un mois. Si je dois me faire un truc dans un langage supporté partout, ça sera en je ne quelle langage... Et niveau sécurité, ce sera surement une passoire...
[^] # Re: Web à tout faire.
Posté par kowalsky . En réponse au journal Des serveurs de la fondation Apache compromis à cause d'un tinyurl, entre autre.. Évalué à 0.
Tu veux dire une interface en (qt/gtk/cocoa/windows) pour chaque site ? Avec la logique métiers coté serveur en un langage (comme aujourd'hui) et coté client en un autre langage ?
Et à chaque modif de ton site, il faut mettre à jour tout les clients ?
Maintenir une compatibilité pour chacun des à peu prêt 20 OS présent (avec les téléphones qui représente une part non négligeable des visites) ?
Toi, tu va relancer les métiers du web :)
Aujourd'hui, si ton client possède une navigateur web récent, roule ma loutre, c'est bon.
Ça serait vraiment plus propre d'utiliser un protocole dédié à chacun de ces types d'application (XMPP ou IRC pour le clavardage en direct, RTSP pour la vidéo, pourquoi pas une extension de NNTP pour gérer le plussage/moinssage sur les forums).
Déjà, premier problème, le réseau. HTTP, c'est du "non connecté". Tu envois ta requette, le serveur repond, ok merci bye. Il y a des petits mecanisme en plus pour faire du keep-alive, mais l'idée est la. Donc, niveau sécurité et ouverture de flux, c'est simple. Tu ouvre le 80 dans un sens, et roule ma loutre. Si tu rajoute tout un tas de protocol avec tout un tas de port dans tout un tas de direction, déjà, pour le nat/pat, c'est foutu et ensuite pour la sécurité réseau, c'est un peu plus poilu (mais on s'en fou, je te l'accorde).
fiable, codée en dur, optimisée pour l'usage auquel elle est destinée, sécurisée car elle sait ce qu'elle devra gérer et sait ce qu'elle ne devra pas gérer
Si tu sais faire ça pour 20 OS, tu dois être riche ou sous payé :)
Quand tu tombes sur des sites Web qui te disent "Viendez sur notre IRC" en te proposant une application javascript, et que tu dois fouiller pour trouver le nom du serveur et du canal, afin de les donner à ton client IRC, celui-la même qui ne pose pas trop de problèmes de sécurité, car il ne parle que l'IRC et n'a pas à interpréter un code non connu à l'avance comme c'est le cas avec du JS, tu te dis que y'a quelque chose de pourri au royaume du Web.
J'aurais plus confiance en la sécurité d'un client xml/javascript qu'en un client (autre que les grosses pointures connu) IRC. Le site web qui fait de l'IRC va juste envoyer les messages au client et recevoir les messages du client. Le client n'interprète rien (à part les styles, les smiley et autre conneries) et de plus personne ne peut connaitre son adresse IP (à part le serveur).
Mais bon, je te dis pas que tu à tord ou que j'ai raison, c'est une question de point de vue.
Écrire un chat (par exemple) pour la vingtaine d'OS sur le marché ou un équivalent en web.
Avec le couple tomcat/java/postgres coté serveur, XML entre le client et le serveur et javascript/html coté client,je pense que j'aurais fini en un mois. Si je dois me faire un truc dans un langage supporté partout, ça sera en je ne quelle langage... Et niveau sécurité, ce sera surement une passoire...