Si tu ne peux pas installer un client lourd, je doute que tu puisses installer:
un serveur http ("client" lourd)
le webmail qui se greffe sur le serveur http
Si le proxy bloque des accès, il le fera autant pour le client lourd que pour le webmail… ah, quoique, les clients lourds sont développés dans cette optique depuis leurs débuts, qui datent probablement des premiers serveurs mail, alors que les webmail eux sont plus récents et prévus pour tourner sur un serveur.
Pas sûr que le 2nd soit aussi simple à configurer qu'un client lourd.
Après, pas obligé d'installer les logiciels natifs, ils sont nombreux à pouvoir être utilisés sans installation dans le registre windows, par exemple. Bon, certes, je ne dirai pas toujours que c'est une bonne chose, ça expose aux risques… mais c'est pareil pour les applis html5, puisque maintenant celles-ci peuvent accéder à des éléments clés des systèmes sur lesquelles elles tournent.
Enfin, perso, j'utilise un webmail (mon fournisseur à en plus le bon goût de proposer 2 webmails différents: squirrel, très utile sur un réseau pourri ou avec un proxy merdique, et roundcube, plus esthétique mais nettement plus lourd), mais ces derniers temps je pense de plus en plus à utiliser un client lourd.
Pourquoi?
pouvoir accéder à mes mails quand je suis hors-ligne
avoir une interface (削除) obligatoirement graphique (削除ここまで) intégrée avec le reste de mon environnement
pouvoir regarder mes mails sans lancer (削除) une usine à gaz qui bouffe toute la ram de mon netbook (削除ここまで) un navigateur internet moderne (je m'amuse parfois avec uzbl, mais la recherche de texte y est lente, et il a quelques fonctionnalités peu pratiques à mon goût. A voir: p'tet que si je le configure mieux…).
moins d'échanges sur le réseau: le wi-fi, ça consomme en électricité (1H sur mon netbook), mon hébergeur mail (associatif) prends sûrement moins cher quand on n'a pas des requêtes chaque seconde (ce qui est plus aisé à configurer sur une appli lourde, je n'ai jamais vu la fréquence d'actu sur un webmail…) et moins de requêtes implique aussi moins de risque de se faire sniffer. Sans compter que l'usage d'un protocole conçu pour la transmission de messages électroniques est très probablement plus efficace que HTML, qui est devenu avec le temps un protocole à tout faire (mais comme on dis chez moi, on peut pas tout faire et le faire bien. La preuve, seul celui qui ne fait rien excelle dans son domaine ;) )
Ces quelques arguments représentent plutôt pas mal les avantages existants (oui, je sais, en théorie, on pourra utiliser HTML5 en local. Mais je parle d'existant, moi, pas de prophéties) d'une application "lourde", sans même parler de la facilité de développer dans le langage de son choix.
Par exemple, je sais que les CGI binaires ça existe, mais il semble que ce soit "pas recommandé"? Donc, déjà, impossible d'utiliser les langages compilés.
Pour ce qui est de la complexité de développer une application graphique lourde… c'est marrant, ce n'est pas l'impression que j'ai sur developpez.com, ou les gens râlent plus contre le fait que JS soit insuffisant, mal conçu, j'en passe et des meilleures, que contre le fait qu'une fenêtre soit complexe à créer avec un framwork d'UI (en même temps, créer une instance d'une classe, et y ajouter des boutons, ça n'a rien de difficile je pense. Sans même parler des RAD - que je n'apprécie pas vraiment, mais bon, ça permet de prototyper en 30s - )
Côté avantages des applis HTML5:
déploiement plus simple
versions plus uniforme (quoique… faut voir si tous les utilisateurs utilisent un brouteur compatible avec la version de HTML5 utilisée huhuhu… parce que ça n'a pas l'air d'être la panacée ce machin, chaque brother voit un bout de la lorgnette différent!)
plus simple à utiliser (disons plutôt que l'utilisateur ayant moins d'options, il est moins perdu)
[^] # Re: Si on veut être honnête ...
Posté par freem . En réponse au journal Les vieux cons et le progrès.... Évalué à 6. Dernière modification le 25 février 2013 à 16:01.
Si tu ne peux pas installer un client lourd, je doute que tu puisses installer:
Si le proxy bloque des accès, il le fera autant pour le client lourd que pour le webmail… ah, quoique, les clients lourds sont développés dans cette optique depuis leurs débuts, qui datent probablement des premiers serveurs mail, alors que les webmail eux sont plus récents et prévus pour tourner sur un serveur.
Pas sûr que le 2nd soit aussi simple à configurer qu'un client lourd.
Après, pas obligé d'installer les logiciels natifs, ils sont nombreux à pouvoir être utilisés sans installation dans le registre windows, par exemple. Bon, certes, je ne dirai pas toujours que c'est une bonne chose, ça expose aux risques… mais c'est pareil pour les applis html5, puisque maintenant celles-ci peuvent accéder à des éléments clés des systèmes sur lesquelles elles tournent.
Enfin, perso, j'utilise un webmail (mon fournisseur à en plus le bon goût de proposer 2 webmails différents: squirrel, très utile sur un réseau pourri ou avec un proxy merdique, et roundcube, plus esthétique mais nettement plus lourd), mais ces derniers temps je pense de plus en plus à utiliser un client lourd.
Pourquoi?
(削除) obligatoirement graphique (削除ここまで)intégrée avec le reste de mon environnement(削除) une usine à gaz qui bouffe toute la ram de mon netbook (削除ここまで)un navigateur internet moderne (je m'amuse parfois avec uzbl, mais la recherche de texte y est lente, et il a quelques fonctionnalités peu pratiques à mon goût. A voir: p'tet que si je le configure mieux…).Ces quelques arguments représentent plutôt pas mal les avantages existants (oui, je sais, en théorie, on pourra utiliser HTML5 en local. Mais je parle d'existant, moi, pas de prophéties) d'une application "lourde", sans même parler de la facilité de développer dans le langage de son choix.
Par exemple, je sais que les CGI binaires ça existe, mais il semble que ce soit "pas recommandé"? Donc, déjà, impossible d'utiliser les langages compilés.
Pour ce qui est de la complexité de développer une application graphique lourde… c'est marrant, ce n'est pas l'impression que j'ai sur developpez.com, ou les gens râlent plus contre le fait que JS soit insuffisant, mal conçu, j'en passe et des meilleures, que contre le fait qu'une fenêtre soit complexe à créer avec un framwork d'UI (en même temps, créer une instance d'une classe, et y ajouter des boutons, ça n'a rien de difficile je pense. Sans même parler des RAD - que je n'apprécie pas vraiment, mais bon, ça permet de prototyper en 30s - )
Côté avantages des applis HTML5: