Justement, en quoi cela va poser des problèmes au serveur d'application de changer le client puisque le serveur, lui, continuera à travailler de la même manière ?
D'une manière plus générale, à partir de quel moment, peut-on considérer qu'une application est 'hébergée' lorsqu'elle a une grosse partie qui tourne en local via javascript ? Cela veut dire qu'une partie de ses fonctionnalités sont effectuées par la machine cliente, donc qu'elle n'est pas vraiment completement hébergée.
Je puis comprendre qu'avec la course à la puissance, c'est dommage de ne pas faire travailler le processeur du client (qui doit travailler plus pour que le serveur gagne plus (en ayant besoin de moins de puissance)). Mais partant de ce principe là quel est le risque de laisser faire tourner sur la machine cliente des scripts modifiés par le client lui même ? Problèmes de sécurités (on ne maitrise pas la validation des données coté client) ? Problème de charge serveur (le client peut taper comme un bourrin sur le serveur) ? Problème de business Model (en donnant au client un certain pouvoir (liberté) est-ce qu'on ne le "libère" pas, au moins en partie, du serveur (plus de connaissance, acteur et pas seulement utilisateur, ...) ?
Je comprends le questionnement de RMS, et même si je comprends que cet intégrisme peut en choquer certains, il n'oblige personne à le suivre, ne force personne à agir comme lui, il ne fait que poser des questions et soulever des questionnements.
Alors que de nombreuses personnes ne savent plus ce qui est sur leur machine, ce qui est sur internet, client mail, web mail, poser le questionnement des applications hébergées est une bonne chose. qui se souciera de la liberté d'une application lorsqu'elle ne tournera pas sur sa machine mais sera louée à l'utilisation ? Car c'est cela qui semble se présenter à l'horizon. Poser le problème aujourd'hui c'est éviter de se retrouver à la ramasse dans 3-5 ans.
[^] # Re: En même temps...
Posté par hervé Couvelard . En réponse au journal RMS et le piège du Javascript. Évalué à 8.
D'une manière plus générale, à partir de quel moment, peut-on considérer qu'une application est 'hébergée' lorsqu'elle a une grosse partie qui tourne en local via javascript ? Cela veut dire qu'une partie de ses fonctionnalités sont effectuées par la machine cliente, donc qu'elle n'est pas vraiment completement hébergée.
Je puis comprendre qu'avec la course à la puissance, c'est dommage de ne pas faire travailler le processeur du client (qui doit travailler plus pour que le serveur gagne plus (en ayant besoin de moins de puissance)). Mais partant de ce principe là quel est le risque de laisser faire tourner sur la machine cliente des scripts modifiés par le client lui même ? Problèmes de sécurités (on ne maitrise pas la validation des données coté client) ? Problème de charge serveur (le client peut taper comme un bourrin sur le serveur) ? Problème de business Model (en donnant au client un certain pouvoir (liberté) est-ce qu'on ne le "libère" pas, au moins en partie, du serveur (plus de connaissance, acteur et pas seulement utilisateur, ...) ?
Je comprends le questionnement de RMS, et même si je comprends que cet intégrisme peut en choquer certains, il n'oblige personne à le suivre, ne force personne à agir comme lui, il ne fait que poser des questions et soulever des questionnements.
Alors que de nombreuses personnes ne savent plus ce qui est sur leur machine, ce qui est sur internet, client mail, web mail, poser le questionnement des applications hébergées est une bonne chose. qui se souciera de la liberté d'une application lorsqu'elle ne tournera pas sur sa machine mais sera louée à l'utilisation ? Car c'est cela qui semble se présenter à l'horizon. Poser le problème aujourd'hui c'est éviter de se retrouver à la ramasse dans 3-5 ans.