Ok pour la mémoire, mais concernant le temps CPU... Le but est d'echanger le
minimum d'info entre le rowser et le serveur... Par exemple pour un webmail,
un nouveau message ne doit pas engendrer plus d'1K de données... Je suis
sceptique sur la charge mémoire et CPU.
Mais ca c'est independant du browser ! On pourrait, comme le disait l'OP, se
contenter d'un OS minimal ou ne tournerait qu'un browser. Plus besoin de
Compiz ou Aero...
Firefox a un projet dans cet optique : un browser ou il n'y a que la page
Web préconfigurée et rien d'autre. Je ne me souviens plus du nom.
Ok pour la mémoire, mais concernant le temps CPU... Le but est d'echanger le
minimum d'info entre le rowser et le serveur... Par exemple pour un webmail,
un nouveau message ne doit pas engendrer plus d'1K de données... Je suis
sceptique sur la charge mémoire et CPU.
Mais ca c'est independant du browser ! On pourrait, comme le disait l'OP, se
contenter d'un OS minimal ou ne tournerait qu'un browser. Plus besoin de
Compiz ou Aero...
Firefox a un projet dans cet optique : un browser ou il n'y a que la page
Web préconfigurée et rien d'autre. Je ne me souviens plus du nom.
Ok pour la mémoire, mais concernant le temps CPU... Le but est d'echanger le
minimum d'info entre le rowser et le serveur... Par exemple pour un webmail,
un nouveau message ne doit pas engendrer plus d'1K de données... Je suis
sceptique sur la charge mémoire et CPU.
Mais ca c'est independant du browser ! On pourrait, comme le disait l'OP, se
contenter d'un OS minimal ou ne tournerait qu'un browser. Plus besoin de
Compiz ou Aero...
Firefox a un projet dans cet optique : un browser ou il n'y a que la page
Web préconfigurée et rien d'autre. Je ne me souviens plus du nom.
Mais le problème n'est pas la taille des données en transit, mais de
la taille qu'elles génèrent une fois manipulées par le navigateur. Un
document Web prend bien plus de place en mémoire une fois parsée,
analysée, l'environnement javascript activé et la page traduite en
image. Sans compter que pour chaque resource graphique, une image en
mémoire vive et en mémoire vidéo est créée, et ce ne sont ni des GIF ni
des JPEG : ce sont des pixmaps.
Mais le problème n'est pas la taille des données en transit, mais de
la taille qu'elles génèrent une fois manipulées par le navigateur. Un
document Web prend bien plus de place en mémoire une fois parsée,
analysée, l'environnement javascript activé et la page traduite en
image. Sans compter que pour chaque resource graphique, une image en
mémoire vive et en mémoire vidéo est créée, et ce ne sont ni des GIF ni
des JPEG : ce sont des pixmaps.
Mais le problème n'est pas la taille des données en transit, mais de
la taille qu'elles génèrent une fois manipulées par le navigateur. Un
document Web prend bien plus de place en mémoire une fois parsée,
analysée, l'environnement javascript activé et la page traduite en
image. Sans compter que pour chaque resource graphique, une image en
mémoire vive et en mémoire vidéo est créée, et ce ne sont ni des GIF ni
des JPEG : ce sont des pixmaps.
> La puissance des PCs reste donc un élément primordial, surtout lorsqu'on
> voit des interfaces telles que Compiz, Aero et celle de MacOSX.
Mais ca c'est independant du browser ! On pourrait, comme le disait l'OP, se
contenter d'un OS minimal ou ne tournerait qu'un browser. Plus besoin de
Compiz ou Aero...
Firefox a un projet dans cet optique : un browser ou il n'y a que la page
Web préconfigurée et rien d'autre. Je ne me souviens plus du nom.
> La puissance des PCs reste donc un élément primordial, surtout lorsqu'on
> voit des interfaces telles que Compiz, Aero et celle de MacOSX.
Mais ca c'est independant du browser ! On pourrait, comme le disait l'OP, se
contenter d'un OS minimal ou ne tournerait qu'un browser. Plus besoin de
Compiz ou Aero...
Firefox a un projet dans cet optique : un browser ou il n'y a que la page
Web préconfigurée et rien d'autre. Je ne me souviens plus du nom.
> La puissance des PCs reste donc un élément primordial, surtout lorsqu'on
> voit des interfaces telles que Compiz, Aero et celle de MacOSX.
Mais ca c'est independant du browser ! On pourrait, comme le disait l'OP, se
contenter d'un OS minimal ou ne tournerait qu'un browser. Plus besoin de
Compiz ou Aero...
Firefox a un projet dans cet optique : un browser ou il n'y a que la page
Web préconfigurée et rien d'autre. Je ne me souviens plus du nom.
Mickaël Wolff wrote:Pierre Goiffon a écrit :
Vous omettez aussi la facilité de mise à jour des applications, le
fait que l'on n'ait plus à se soucier des dépendances et
compatibilités entre middlewares et autres frameworks, etc etc...
Le problème est résolu depuis maintenant plusieurs années :
<http://www.debian.org>. Les systèmes de package ne permettent plus
d'avoir ce genre de problèmes. Du moins, sur des OS corrects.
Je manque d'information pour avoir un réel jugement là-dessus.
J'en discutais encore pas plus tard qu'hier avec un ami : j'ai très
sensiblement l'impression que ces systèmes de paquets en vogue dans
plusieurs distributions Linux
marchent bien sur un écosystème bien
délimité d'applications qui sont bien livrées en versions stables, etc.
Je ne suis pas persuadé que tous les éditeurs d'applications - et en
particulier les applications métiers, internes à une entreprise -
puissent se permettre d'arriver à ce résultat presque idéal.+
Mickaël Wolff wrote:
Pierre Goiffon a écrit :
Vous omettez aussi la facilité de mise à jour des applications, le
fait que l'on n'ait plus à se soucier des dépendances et
compatibilités entre middlewares et autres frameworks, etc etc...
Le problème est résolu depuis maintenant plusieurs années :
<http://www.debian.org>. Les systèmes de package ne permettent plus
d'avoir ce genre de problèmes. Du moins, sur des OS corrects.
Je manque d'information pour avoir un réel jugement là-dessus.
J'en discutais encore pas plus tard qu'hier avec un ami : j'ai très
sensiblement l'impression que ces systèmes de paquets en vogue dans
plusieurs distributions Linux
marchent bien sur un écosystème bien
délimité d'applications qui sont bien livrées en versions stables, etc.
Je ne suis pas persuadé que tous les éditeurs d'applications - et en
particulier les applications métiers, internes à une entreprise -
puissent se permettre d'arriver à ce résultat presque idéal.+
Mickaël Wolff wrote:Pierre Goiffon a écrit :
Vous omettez aussi la facilité de mise à jour des applications, le
fait que l'on n'ait plus à se soucier des dépendances et
compatibilités entre middlewares et autres frameworks, etc etc...
Le problème est résolu depuis maintenant plusieurs années :
<http://www.debian.org>. Les systèmes de package ne permettent plus
d'avoir ce genre de problèmes. Du moins, sur des OS corrects.
Je manque d'information pour avoir un réel jugement là-dessus.
J'en discutais encore pas plus tard qu'hier avec un ami : j'ai très
sensiblement l'impression que ces systèmes de paquets en vogue dans
plusieurs distributions Linux
marchent bien sur un écosystème bien
délimité d'applications qui sont bien livrées en versions stables, etc.
Je ne suis pas persuadé que tous les éditeurs d'applications - et en
particulier les applications métiers, internes à une entreprise -
puissent se permettre d'arriver à ce résultat presque idéal.+
A vrai dire, le système de gestion de paquetages est presque l'essentiel
d'une distrib linux à lui tout seul.
Un problème courant est la gestion sur une même machine de plusieurs
applications métier ayant des dépendances incompatibles. Certains
gestionnaires de paquetages permettent d'avoir plusieurs versions d'un
même paquetage en parallèle (Portage - le gestionnaire de paquetage de
Gentoo - entre autres), mais ça ne simplifie pas nécessairement
l'administration, et ça ne résoud pas forcément tous les cas de figure
possibles.
Après se pose effectivement la question de la gestion et de la
maintenance du "packaging" d'une appli pour X gestionnaires de paquetage
différents.
A vrai dire, le système de gestion de paquetages est presque l'essentiel
d'une distrib linux à lui tout seul.
Un problème courant est la gestion sur une même machine de plusieurs
applications métier ayant des dépendances incompatibles. Certains
gestionnaires de paquetages permettent d'avoir plusieurs versions d'un
même paquetage en parallèle (Portage - le gestionnaire de paquetage de
Gentoo - entre autres), mais ça ne simplifie pas nécessairement
l'administration, et ça ne résoud pas forcément tous les cas de figure
possibles.
Après se pose effectivement la question de la gestion et de la
maintenance du "packaging" d'une appli pour X gestionnaires de paquetage
différents.
A vrai dire, le système de gestion de paquetages est presque l'essentiel
d'une distrib linux à lui tout seul.
Un problème courant est la gestion sur une même machine de plusieurs
applications métier ayant des dépendances incompatibles. Certains
gestionnaires de paquetages permettent d'avoir plusieurs versions d'un
même paquetage en parallèle (Portage - le gestionnaire de paquetage de
Gentoo - entre autres), mais ça ne simplifie pas nécessairement
l'administration, et ça ne résoud pas forcément tous les cas de figure
possibles.
Après se pose effectivement la question de la gestion et de la
maintenance du "packaging" d'une appli pour X gestionnaires de paquetage
différents.
Un problème courant est la gestion sur une même machine de plusieurs
applications métier ayant des dépendances incompatibles. Certains
gestionnaires de paquetages permettent d'avoir plusieurs versions d'un
même paquetage en parallèle (Portage - le gestionnaire de paquetage de
Gentoo - entre autres), mais ça ne simplifie pas nécessairement
l'administration, et ça ne résoud pas forcément tous les cas de figure
possibles.
Dans ces cas, je ne pense pas qu'il puisse y avoir de mécanismes
triviaux. Et même avec des gestionnaires de paquets, qui accepte la
présence de version de logiciels incompatibles, on est pas à l'abri de
soucis. Pour exemple, une péripétie qui m'avait bien bloqué six mois.
J'avis développé un module Apache (en C, c'est pour revenir en charte ;)
) permettant de loguer le trafic par vhost dans une base MySQL. Au début
du développement, aucun problèmes, le module se chargeait. Mais vers la
fin, Apache en chargeant le module segfaultait. J'ai réussi à déterminer
que le segfault intervenait lors du chargement du module PHP pour
Apache, quand le module MySQL de PHP était aussi chargé. Et que mon
module se chargeait correctement s'il précédait le chargement du module
PHP, mais dans ce cas là c'était le module MySQL de PHP qui entraînait
le segfault. Ce n'est que de très nombreux mois plus tard que je me suis
rendu compte que, le module MySQL du module PHP pour Apache était
compilé avec une version de la libmysqlclient différente de celle que
j'utilisais pour mon module.
Bref, les versions ça pue, et même avec un système de gestion des
versions, il n'y a que l'expérience qui fait la différence (parce qu'on
ne m'y reprendra pas).
Un problème courant est la gestion sur une même machine de plusieurs
applications métier ayant des dépendances incompatibles. Certains
gestionnaires de paquetages permettent d'avoir plusieurs versions d'un
même paquetage en parallèle (Portage - le gestionnaire de paquetage de
Gentoo - entre autres), mais ça ne simplifie pas nécessairement
l'administration, et ça ne résoud pas forcément tous les cas de figure
possibles.
Dans ces cas, je ne pense pas qu'il puisse y avoir de mécanismes
triviaux. Et même avec des gestionnaires de paquets, qui accepte la
présence de version de logiciels incompatibles, on est pas à l'abri de
soucis. Pour exemple, une péripétie qui m'avait bien bloqué six mois.
J'avis développé un module Apache (en C, c'est pour revenir en charte ;)
) permettant de loguer le trafic par vhost dans une base MySQL. Au début
du développement, aucun problèmes, le module se chargeait. Mais vers la
fin, Apache en chargeant le module segfaultait. J'ai réussi à déterminer
que le segfault intervenait lors du chargement du module PHP pour
Apache, quand le module MySQL de PHP était aussi chargé. Et que mon
module se chargeait correctement s'il précédait le chargement du module
PHP, mais dans ce cas là c'était le module MySQL de PHP qui entraînait
le segfault. Ce n'est que de très nombreux mois plus tard que je me suis
rendu compte que, le module MySQL du module PHP pour Apache était
compilé avec une version de la libmysqlclient différente de celle que
j'utilisais pour mon module.
Bref, les versions ça pue, et même avec un système de gestion des
versions, il n'y a que l'expérience qui fait la différence (parce qu'on
ne m'y reprendra pas).
Un problème courant est la gestion sur une même machine de plusieurs
applications métier ayant des dépendances incompatibles. Certains
gestionnaires de paquetages permettent d'avoir plusieurs versions d'un
même paquetage en parallèle (Portage - le gestionnaire de paquetage de
Gentoo - entre autres), mais ça ne simplifie pas nécessairement
l'administration, et ça ne résoud pas forcément tous les cas de figure
possibles.
Dans ces cas, je ne pense pas qu'il puisse y avoir de mécanismes
triviaux. Et même avec des gestionnaires de paquets, qui accepte la
présence de version de logiciels incompatibles, on est pas à l'abri de
soucis. Pour exemple, une péripétie qui m'avait bien bloqué six mois.
J'avis développé un module Apache (en C, c'est pour revenir en charte ;)
) permettant de loguer le trafic par vhost dans une base MySQL. Au début
du développement, aucun problèmes, le module se chargeait. Mais vers la
fin, Apache en chargeant le module segfaultait. J'ai réussi à déterminer
que le segfault intervenait lors du chargement du module PHP pour
Apache, quand le module MySQL de PHP était aussi chargé. Et que mon
module se chargeait correctement s'il précédait le chargement du module
PHP, mais dans ce cas là c'était le module MySQL de PHP qui entraînait
le segfault. Ce n'est que de très nombreux mois plus tard que je me suis
rendu compte que, le module MySQL du module PHP pour Apache était
compilé avec une version de la libmysqlclient différente de celle que
j'utilisais pour mon module.
Bref, les versions ça pue, et même avec un système de gestion des
versions, il n'y a que l'expérience qui fait la différence (parce qu'on
ne m'y reprendra pas).
"Mihamina Rakotomandimby (R12y)" wrote :Je n'ai rien contre cet état des choses (c'est quand même mon
gagne pain), j'en cherche juste la raison.
Deux boîtes parmi d'autres - Google et Mozilla - ont tout intérêt
(commercial) à drainer l'utilisateur de son poste avec ses applis
onboard vers internet et les services en ligne.
"Mihamina Rakotomandimby (R12y)" <mihamina@infogerance.us> wrote :
Je n'ai rien contre cet état des choses (c'est quand même mon
gagne pain), j'en cherche juste la raison.
Deux boîtes parmi d'autres - Google et Mozilla - ont tout intérêt
(commercial) à drainer l'utilisateur de son poste avec ses applis
onboard vers internet et les services en ligne.
"Mihamina Rakotomandimby (R12y)" wrote :Je n'ai rien contre cet état des choses (c'est quand même mon
gagne pain), j'en cherche juste la raison.
Deux boîtes parmi d'autres - Google et Mozilla - ont tout intérêt
(commercial) à drainer l'utilisateur de son poste avec ses applis
onboard vers internet et les services en ligne.
Google, c'est évident. Mais Mozilla, là, je ne vois pas. D'abord,
ce n'est pas une "boite" (au sens 'entreprise commerciale').
Ensuite, je ne suis au courant d'aucune appli hébergées fournie
par la fondation mozilla. Là, je veux bien que tu t'expliques...
Google, c'est évident. Mais Mozilla, là, je ne vois pas. D'abord,
ce n'est pas une "boite" (au sens 'entreprise commerciale').
Ensuite, je ne suis au courant d'aucune appli hébergées fournie
par la fondation mozilla. Là, je veux bien que tu t'expliques...
Google, c'est évident. Mais Mozilla, là, je ne vois pas. D'abord,
ce n'est pas une "boite" (au sens 'entreprise commerciale').
Ensuite, je ne suis au courant d'aucune appli hébergées fournie
par la fondation mozilla. Là, je veux bien que tu t'expliques...
Thierry a écrit :Ok pour la mémoire, mais concernant le temps CPU... Le but est d'echanger
le minimum d'info entre le rowser et le serveur... Par exemple pour un
webmail, un nouveau message ne doit pas engendrer plus d'1K de données...
Je suis sceptique sur la charge mémoire et CPU.
IMAP est un protocole bien moins gourmant si on va par là.
Mais le problème n'est pas la taille des données en transit, mais de la
taille qu'elles génèrent une fois manipulées par le navigateur. Un
document Web prend bien plus de place en mémoire une fois parsée,
analysée, l'environnement javascript activé et la page traduite en image.
Sans compter que pour chaque resource graphique, une image en mémoire vive
et en mémoire vidéo est créée, et ce ne sont ni des GIF ni des JPEG : ce
sont des pixmaps.
Quand à la charge CPU, elle est énorme pour ce qui est fait, à savoir
afficher une interface.Mais ca c'est independant du browser ! On pourrait, comme le disait l'OP,
se contenter d'un OS minimal ou ne tournerait qu'un browser. Plus besoin
de Compiz ou Aero...
Bien sûr que si, puisque le navigateur deviendrait le pourvoyeur de ces
effets.
Flash en est un exemple assez flagrant, et aujourd'hui, SVG combiné au
javascript permettent de bientôt atteindre ce type de fonctionnalités. Et
personnellement, je pense que la consommation en ressource sera bien plus
grande dans un navigateur que dans une application native. Pour des
raisons assez évidentes.
Thierry a écrit :
Ok pour la mémoire, mais concernant le temps CPU... Le but est d'echanger
le minimum d'info entre le rowser et le serveur... Par exemple pour un
webmail, un nouveau message ne doit pas engendrer plus d'1K de données...
Je suis sceptique sur la charge mémoire et CPU.
IMAP est un protocole bien moins gourmant si on va par là.
Mais le problème n'est pas la taille des données en transit, mais de la
taille qu'elles génèrent une fois manipulées par le navigateur. Un
document Web prend bien plus de place en mémoire une fois parsée,
analysée, l'environnement javascript activé et la page traduite en image.
Sans compter que pour chaque resource graphique, une image en mémoire vive
et en mémoire vidéo est créée, et ce ne sont ni des GIF ni des JPEG : ce
sont des pixmaps.
Quand à la charge CPU, elle est énorme pour ce qui est fait, à savoir
afficher une interface.
Mais ca c'est independant du browser ! On pourrait, comme le disait l'OP,
se contenter d'un OS minimal ou ne tournerait qu'un browser. Plus besoin
de Compiz ou Aero...
Bien sûr que si, puisque le navigateur deviendrait le pourvoyeur de ces
effets.
Flash en est un exemple assez flagrant, et aujourd'hui, SVG combiné au
javascript permettent de bientôt atteindre ce type de fonctionnalités. Et
personnellement, je pense que la consommation en ressource sera bien plus
grande dans un navigateur que dans une application native. Pour des
raisons assez évidentes.
Thierry a écrit :Ok pour la mémoire, mais concernant le temps CPU... Le but est d'echanger
le minimum d'info entre le rowser et le serveur... Par exemple pour un
webmail, un nouveau message ne doit pas engendrer plus d'1K de données...
Je suis sceptique sur la charge mémoire et CPU.
IMAP est un protocole bien moins gourmant si on va par là.
Mais le problème n'est pas la taille des données en transit, mais de la
taille qu'elles génèrent une fois manipulées par le navigateur. Un
document Web prend bien plus de place en mémoire une fois parsée,
analysée, l'environnement javascript activé et la page traduite en image.
Sans compter que pour chaque resource graphique, une image en mémoire vive
et en mémoire vidéo est créée, et ce ne sont ni des GIF ni des JPEG : ce
sont des pixmaps.
Quand à la charge CPU, elle est énorme pour ce qui est fait, à savoir
afficher une interface.Mais ca c'est independant du browser ! On pourrait, comme le disait l'OP,
se contenter d'un OS minimal ou ne tournerait qu'un browser. Plus besoin
de Compiz ou Aero...
Bien sûr que si, puisque le navigateur deviendrait le pourvoyeur de ces
effets.
Flash en est un exemple assez flagrant, et aujourd'hui, SVG combiné au
javascript permettent de bientôt atteindre ce type de fonctionnalités. Et
personnellement, je pense que la consommation en ressource sera bien plus
grande dans un navigateur que dans une application native. Pour des
raisons assez évidentes.
Bruno Desthuilliers wrote
:Google, c'est évident. Mais Mozilla, là, je ne vois pas. D'abord,
ce n'est pas une "boite" (au sens 'entreprise commerciale').
Si. C'est la filiale "Mozilla Corporation" de "Mozilla Foundation".
Un lien au cas où :
<http://www.geckozone.org/articles/2006/05/01/116-mozilla-corporation
-la-societe-de-la-fondation-mozilla-entrevue-avec-tristan-nitot>Ensuite, je ne suis au courant d'aucune appli hébergées fournie
par la fondation mozilla. Là, je veux bien que tu t'expliques...
Je n'ai pas écrit que que la fondation Mozilla hébergeait des
applications en ligne. En revanche, la fondation a tout intérêt à
promouvoir les applications en ligne, pour renforcer la place de son
navigateur (Firefox) au coeur de la machine de l'utilisateur
(pro/perso et windows/mac/linux).
Bruno Desthuilliers <bdesth.quelquechose@free.quelquepart.fr> wrote
:
Google, c'est évident. Mais Mozilla, là, je ne vois pas. D'abord,
ce n'est pas une "boite" (au sens 'entreprise commerciale').
Si. C'est la filiale "Mozilla Corporation" de "Mozilla Foundation".
Un lien au cas où :
<http://www.geckozone.org/articles/2006/05/01/116-mozilla-corporation
-la-societe-de-la-fondation-mozilla-entrevue-avec-tristan-nitot>
Ensuite, je ne suis au courant d'aucune appli hébergées fournie
par la fondation mozilla. Là, je veux bien que tu t'expliques...
Je n'ai pas écrit que que la fondation Mozilla hébergeait des
applications en ligne. En revanche, la fondation a tout intérêt à
promouvoir les applications en ligne, pour renforcer la place de son
navigateur (Firefox) au coeur de la machine de l'utilisateur
(pro/perso et windows/mac/linux).
Bruno Desthuilliers wrote
:Google, c'est évident. Mais Mozilla, là, je ne vois pas. D'abord,
ce n'est pas une "boite" (au sens 'entreprise commerciale').
Si. C'est la filiale "Mozilla Corporation" de "Mozilla Foundation".
Un lien au cas où :
<http://www.geckozone.org/articles/2006/05/01/116-mozilla-corporation
-la-societe-de-la-fondation-mozilla-entrevue-avec-tristan-nitot>Ensuite, je ne suis au courant d'aucune appli hébergées fournie
par la fondation mozilla. Là, je veux bien que tu t'expliques...
Je n'ai pas écrit que que la fondation Mozilla hébergeait des
applications en ligne. En revanche, la fondation a tout intérêt à
promouvoir les applications en ligne, pour renforcer la place de son
navigateur (Firefox) au coeur de la machine de l'utilisateur
(pro/perso et windows/mac/linux).