Tout HTTP: pourquoi?

Salut,
Le 31/07/2008 10:05:01 +0200, Sergio <laposte@serge.delbono.net.invalid> a
écrit:

Mihamina Rakotomandimby vient de nous annoncer :

Sergio wrote:

Ou le SVG qui a mis vraiment du temps à s'imposer dans les navigateurs
et a ouvert une (autre) voie royale à Flash.

Et devine ce qui se passe maintenant:
http://www.google.fr/search?q­obe+abandonne+svg

Si le SVG est géré en natif dans le navigateur, son plugin devient
inutile...

Bon, il n' y a que Firefox qui le fait, mais bon...

Qui fait quoi ? Supporter SVG nativement ?
C'est certes mieux qu'IE, mais Firefox gère SVG de manière bien plus
partielle que d'autres (Opera et Webkit par exemple) :D
http://www.codedread.com/svg-support.php


@+
--
rm - http://opera-fr.com
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

rm a présenté l'énoncé suivant :

Si le SVG est géré en natif dans le navigateur, son plugin devient
inutile...

Bon, il n' y a que Firefox qui le fait, mais bon...

Qui fait quoi ? Supporter SVG nativement ?
C'est certes mieux qu'IE, mais Firefox gère SVG de manière bien plus
partielle que d'autres (Opera et Webkit par exemple) :D
http://www.codedread.com/svg-support.php

Un point de moins pour SVG : Les différentes extensions du langage,
plus ou moins propriétaires.

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Le 31/07/2008 13:33:36 +0200, Sergio <laposte@serge.delbono.net.invalid> a
écrit:

rm a présenté l'énoncé suivant :

Si le SVG est géré en natif dans le navigateur, son plugin devient
inutile...

Bon, il n' y a que Firefox qui le fait, mais bon...

Qui fait quoi ? Supporter SVG nativement ?
C'est certes mieux qu'IE, mais Firefox gère SVG de manière bien plus
partielle que d'autres (Opera et Webkit par exemple) :D
http://www.codedread.com/svg-support.php

Un point de moins pour SVG : Les différentes extensions du langage, plus
ou moins propriétaires.

Des extensions propriétaires dans SVG ? Où ça ?

Si tu parles de feu les spécificités d'Adobe, il suffit de les ignorer, ce
que fait Opera:
http://www.opera.com/docs/specs/#graphics
et se contenter des spécification du W3C:
http://www.w3.org/TR/SVG11/
http://www.w3.org/TR/SVGMobile12/
http://www.w3.org/TR/SVGMobile

Différentes possibilités offertes par SVG:
http://dev.opera.com/articles/svg/
et associéés à l'élément <video> évoquée plus haut :
http://people.opera.com/howcome/2007/video/svg/clip-move.svg
http://people.opera.com/howcome/2007/video/svg/video-reflect.svg
http://people.opera.com/howcome/2007/video/svg/video-filter.svg
(ne fonctionnent actuellement qu'avec la dernière version de dev d'Opera
supportant <video>, 3D canvas et File I/O : voir
http://labs.opera.com/news/2008/07/18/)
et même http://www.double.co.nz/video_test/video.svg qui devrait
fonctionner avec les dernières nightlies de Firefox 3.1

@+
--
rm - Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

"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.

--
Antoine

Pierre Goiffon a écrit :

(Chouette un petit débat pour nous réveiller cet été !)

Ouais, et il est même pas parti en troll, malgré ma présence ;)

Je précisait dans un autre message (et le refais donc ici) qu'en
rédigeant ma réponse au posteur initial j'avais en tête une utilisation
professionnelle.

Si tu maîtrise de bout en bout, effectivement la centralisation via
le Web a un intérêt. Mais dans ce cas, il est aussi possible d'avoir un
système d'information disposant à la fois d'interface Web que
d'interfaces natives. Ce qui est parfois un confort non négligeable (je
penses aux logiciels de saisie, dans lesquelles la vitesse de saisie est
importante, et la lenteur du web et sa fiabilité peuvent y être un
problème).

Pour les particuliers, cela peut être un peu plus difficile. J'ai en
souvenir un ami ayant choisi une plateforme de blog qui n'offre aucune
garantie de services et aucun moyen de récupérer ses billets, malgrès
mes mises en garde... Je lui prévois des lendemains difficiles... Voilà
pour l'anecdote.

On peut observer le même comportement avec les sauvegardes. Il n'y a
qu'au lendemain d'un crash disk ayant entraîné la perte de centaines de
photos de vacances qu'une réaction peut être attendue.

Il semble assez peu probable que le législateur s'empare de ces
questions, en attendant on peut espérer que les "early adopters" (même
si le nombre actuel d'utilisateur de services en ligne est très élevé)
auront accumulé du retour d'expérience sur ces questions, et que la
relation utilisateur/fournisseur dans le cadre du grand public
s'améliorera mécaniquement.

Il ne tient qu'à nous d'en parler autour de nous, en espérant que nos
efforts auront un écho.

:D
Vous y allez fort vous...

C'est ma tendance à la paranoïa. Et puis, j'ai travaillé chez un ISP,
ça n'aide pas à faire confiance.

Les débiles des équipes techniques qui s'acharnent à gérer les logiciels
sur des parcs informatiques toujours plus complexes sont bienheureux de
toute la bienveillance que vous leur témoignez.

Ah non, quand je penses aux débiles, ce sont ceux qui ne parviennent
pas à conceptualiser que le web possède une certaine profondeur, ceux
qui l'aplatissent dans leur navigateur, qui sont capable de parler du
web en croyant parler de l'Internet. Je suis désolé de ce biais, mais
j'ai trop longtemps travaillé en support technique, les personnes
supportées étant des professionnels (des gens sensés savoir ce qu'ils
font). Je préfères partir du bas en considérant l'utilisateur comme un
débile pour être exceptionnellement surpris de manière agréable, plutôt
que d'être systématiquement déçu.

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.

Le client/serveur a très rapidement démontré sa complexité de gestion.

Alors pourquoi le Web s'impose ? ;)

Si vous préférez ne pas passer pour un "débile" et dépenser de l'argent
dans des proportions considérables, libre à vous. La large majorité des
professionnels n'est pas de cet avis et recherche de meilleures
solutions depuis au moins 15 ans... Il se trouve que le web s'avère
prometteur (mais avec des solutions encore trop jeunes). on peut citer
aussi les serveurs lames, les mécanismes de VM, etc... Le besoin est là
depuis un moment.

J'ai toujours pensé que la meilleurs solution était la plus adaptée
au problème. Et c'est pourquoi je ne tolère pas cet engouement vers le
tout-HTTP.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Thierry a écrit :

Je ne pense pas que la puissance soit maintenant le critere. Bien qu'il
faille encore faire tourner l'OS.

La puissance est très importante. L'analyse des fichiers XML peuvent
être très consommatrice en temps CPU et en mémoire (surtout). La
puissance des PCs reste donc un élément primordial, surtout lorsqu'on
voit des interfaces telles que Compiz, Aero et celle de MacOSX.

De plus, il se peut qu'avec les problèmes de sécurité, on s'oriente
vers une isolation des fenêtres de navigation, avec un processus par
domaine consulté. Ou encore d'autres mécanismes pour améliorer la sécurité.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Mickaël Wolff wrote:

J'ai toujours pensé que la meilleurs solution était la plus adaptée au
problème. Et c'est pourquoi je ne tolère pas cet engouement vers le
tout-HTTP.

Votre 1ere phrase me fait très plaisir à lire (surtout suite à un
commentaire assez sec rédigé hier)

A la fin des années 90, quasiment tous les éditeurs se sont crus obligés
de faire des versions Web de leurs produits, les journaux spécialisés
titraient en gros que le tout Web arrivait... et ça a tourné court,
évidemment !
Je me souviens de l'interface Web d'administration de IIS 4... enfin bref.

Maintenant que des technologies de RIA/RDA fleurissent et que leurs
éditeurs respectifs ont besoin de beaucoup de marketing pour se faire
une place sur le marché, on revient assez facilement dans la même
situation...

Mais la différence est que des applications Web, il y en a des tonnes
qui ont été écrites depuis, et que le retour d'expérience est là. Et on
ne peut que constater que les services en ligne, si ce n'est pas pas la
panacée et que ça ne va pas remplacer tout le reste (haha, le 0 papier,
on en rigole encore), hé bien c'est quand même bien présent dans notre
quotidien, et ça va le rester !

"Mickaël Wolff" <mickael.wolff@laposte.net> a écrit dans le message de news:
48930f42$0$4523$426a74cc@news.free.fr...

La puissance est très importante. L'analyse des fichiers XML peuvent
être très consommatrice en temps CPU et en mémoire (surtout).

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.

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...

De plus, il se peut qu'avec les problèmes de sécurité, on s'oriente vers
une isolation des fenêtres de navigation, avec un processus par domaine
consulté. Ou encore d'autres mécanismes pour améliorer la sécurité.

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.

Oops, ma réponse est partie trop vite... désolé


Mickaël Wolff wrote:

Pierre Goiffon a écrit :

Je précisait dans un autre message (et le refais donc ici) qu'en
rédigeant ma réponse au posteur initial j'avais en tête une
utilisation professionnelle.

Si tu maîtrise de bout en bout, effectivement la centralisation via le
Web a un intérêt.

On peut considérer les 2 cas : les applications Web toutes en interne,
et donc on en revient au modèle serveur / terminaux, du centralisé, "du
simple" pour résumer un peu vite.

Mais l'intérêt des services en ligne réside avant tout dans la souplesse
qu'ils apportent : j'ai besoin de tel logiciel pendant 3 semaines ? Paf,
c'est fait. Pas de longues phases d'intégration, de paramétrage etc, un
clic et un no de cb et l'accès est ouvert.

Beaucoup de TPE et même PME utilisent des applications asp, de
l'infogérance, etc, bref tout externalisé : les coûts sont sensiblement
diminués, les taux de disponibilité remontent en flèche, etc.
Mais il reste bien sûr tous les prb sur la relation client-fournisseur
que nous avons déjà évoqués ailleurs dans le fil.

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.+

Cet ami m'évoquait par exemple tous les prb qu'il a pu avoir sur Debian
en tentant l'installation d'applications un peu "exotiques"... Il me
citait Conqueror (non pas le navigateur de KDE, c'est un navigateur
aussi mais un autre : http://conkeror.org/). Et il a basculé voilà un
moment sous FreeBSD.

Le client/serveur a très rapidement démontré sa complexité de gestion.

Alors pourquoi le Web s'impose ? ;)

Pas compris ?

Pierre Goiffon a écrit :

Maintenant que des technologies de RIA/RDA fleurissent et que leurs
éditeurs respectifs ont besoin de beaucoup de marketing pour se faire
une place sur le marché, on revient assez facilement dans la même
situation...

Les cycles technologiques informatiques, il n'y a que ça de vrai :-D


Pierre Goiffon a écrit :

Oops, ma réponse est partie trop vite... désolé

Pas de problème. Mais ça se soigne ;) Je n'en dirais pas plus de peur
de ne plus passer les filtres anti-spam.

[...]

Je ne vais pas commenter outre mesure ce que je viens d'éluder, étant
globalement sur la même longueur d'onde.

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.+

Le manque de formation dans la création des paquets, et la gestion
d'un entrepôt (serveur FTP/Web interne) serait le seul obstacle à une
telle prouesse. Je ne penses pas que pour des sociétés où l'on créé du
logiciel, ce soit insurmontable.

Maintenant, il faut expliquer que se coût (formation, création des
paquets) peut être réellement un gain : diminution des coups relatifs au
support lié à l'installation de l'application, homogénéisation de
l'installation, etc. Sans compter que pour peu que les mises à jour
soient automatiques, l'ensemble du parc est mis à jour dans un délais
très réduit.

Cet ami m'évoquait par exemple tous les prb qu'il a pu avoir sur Debian
en tentant l'installation d'applications un peu "exotiques"... Il me
citait Conqueror (non pas le navigateur de KDE, c'est un navigateur
aussi mais un autre : http://conkeror.org/). Et il a basculé voilà un
moment sous FreeBSD.

Je viens d'installer le paquet en deux clique de souris (bon, en fait
neuf, sans compter la saisie du mot de passe root et « conkeror » pour
chercher le paquet). Mais peut-être avait-il tenter d'installer un
paquet qui requérait des dépendances qu'il n'a pas su résoudre.

Je me demandes comment il s'en sort avec les deux systèmes de
paquetage alors qu'il avait des problèmes sous Debian :p

Boutade à part, je t'invite à te pencher sur un système de gestion
des applications qui écrase sans conteste le standard sous MS Windows.

Le client/serveur a très rapidement démontré sa complexité de gestion.

Alors pourquoi le Web s'impose ? ;)

Pas compris ?

Je te charriait sur le fait que le Web, c'est un protocole
client/serveur, et qu'étrangement tu les opposais.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org