Journal Google Gears, le retour de l'incompatibilité des navigateurs Web

Posté par  .
Étiquettes :
0
31
mai
2007
Les faits : http://www.readwriteweb.com/archives/google_gears_browser_bo(...)
http://fr.techcrunch.com/2007/05/31/google-gears-permettra-d(...)
- Google lance Gears, un plugin open-source pour que les applications web comme GMail marchent même si on n'est pas connecté à Internet
- Gears est compatible avec une suite très limitée de navigateurs, bref mon chouchou Konqueror est encore dans les choux (pas assez dissaïdor compliant pour participer aux discussions ?)

Les applis web hors connexion, c'est la mode. Bonne idée à la base, je me demande comment cette nouvelle fonctionnalité va fonctionner pour n'utiliser que des standards ouverts reconnus et implémentables par tous.

En l'occurrence, comme Firefox a décidé que cela serait la grande fonctionnalité de la version 3, est-ce que quelqu'un pourrait expliquer le fonctionnement à un béotien comme moi ?

Et quelqu'un peut-il me rassurer en disant que à partir du moment où un navigateur gère correctement les standards du web (HTML, CSS, EcmaScript), il n'aura pas de problème ?

  • # open source

    Posté par  . Évalué à 5.

    Pour le coup, l'extension est open-source, donc n'importe qui peut a priori le porter sur konqueror.

    L'API n'étant pas stabilisé, je comprends parfaitement la décision de google de ne supporter qu'un ensemble limité de navigateur (Firefox partout et IE sous windows) alors que l'extension se voir profondement modifié dans les prochains mois.

  • # Gmail offline

    Posté par  . Évalué à 8.

    Dans http://www.readwriteweb.com/archives/google_gears_browser_bo(...) il y a un petit sondage qui plébiscite Gmail offline.

    Certes l'ergonomie de Gmail est très séduisante (à titre tout à fait personnel je la préfère à tous les autres logiciels de messagerie) mais consulter ses emails offline est possible depuis la nuit des temps avec n'importe quel logiciel de messagerie.

    Si Google Gears sert à réinventer Thunderbird en tant qu'extension à Firefox je ne vois pas trop son intérêt.

    BeOS le faisait il y a 20 ans !

    • [^] # Re: Gmail offline

      Posté par  . Évalué à 7.

      Oui, si le Web 3.0, c'est Google Gears/Thunderbird, le Web 4.0, c'est Mutt (mais il faudra un Dual Core 4GHz 4 Go de RAM pour le faire tourner)

    • [^] # Re: Gmail offline

      Posté par  . Évalué à 1.

      Si Google Gears sert à réinventer Thunderbird en tant qu'extension à Firefox je ne vois pas trop son intérêt.

      L'intérêt est pour le Gentil Google de centraliser la gestion de tes données perso.

    • [^] # Re: Gmail offline

      Posté par  (site web personnel) . Évalué à 5.

      Si Google Gears sert à réinventer Thunderbird en tant qu'extension à Firefox je ne vois pas trop son intérêt.

      Avoir la même interface online et offline, tout simplement.
      Thunderbird ne fait pas de online (dans le sens "web", sans installation, sur n'importe quelle machine), du coup gmail aura un avantage en fonctionnalités : accessible online par le web, offline aussi. thunderbird restera "nécessaire à installer et configurer sur une machine"

      • [^] # Re: Gmail offline

        Posté par  (site web personnel) . Évalué à 1.

        enfin pas totalement quand même...
        car t'as beau sauvegarder les données dans reader (comme c'est faisable actuellement) si tu n'as pas lancé le soft et chargé tout ce qui est js ou autre, tu peux toujours te brosser pour bosser offline...

        En clair, c'est joli leur techno mais ça oblige à lancer l'application (gmail par exemple) en étant connecté avant de se déconnecter au contraire de thunderbird ou tout autre client lourd et se connecter ensuite pour envoyer/recevoir les données

        • [^] # Re: Gmail offline

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          dans un navigateur, tu as ce qu'on appelle un "cache", qui comme son nom l'indique, met en cache les pages web que tu visites.

          Encore mieux : tu as généralement une fonction "Offline" sur ton navigateur, qui te permet de surfer... offline. (seulement sur les sites qui sont dans le cache bien évidement).

          Encore mieux mieux : les specs des nouvelles fonctionnalités offlines, proposent plein de petites choses qui permettent d'informer le navigateur ou l'application des capacités offline de l'appli.

          Par exemple, quand l'utilisateur met son navigateur offline ou online, un evenement dom est généré. L'appli en cours peut alors être informé du passage et agir en conséquence. Par exemple, gears, si il voit que le browser est offline, mettra les nouveaux mails en attente d'envoi, en les stockant en local via une autre api, Storage (dans firefox, c'est du sqlite derrière), plutôt que de tenter de les envoyer directement sur le serveur. Et au passage en online, gears est informé, donc peut alors faire la synchro avec gmail, envoyer les mails en attente etc...

          Au niveau de l'appli, une page web est très souvent liés à des feuilles de styles, images et d'autres fichiers, qui ne sont pas forcément chargés tout de suite par le navigateur. Avec les nouvelles possibilités, il est possible d'indiquer avec la balise link, les ressources qui doivent être absolument stockées en locales car nécessaire pour le mode offline. Ces ressources peuvent être notamment d'autres pages web de l'application.

          http://xulfr.org/news/2007/02/14/199-application-web-offline(...)

          • [^] # Re: Gmail offline

            Posté par  . Évalué à -2.

            C'est ta façon de nous dire que firefox va consommer encore plus de RAM que nécessaire ? Et qu'il va encore plus faire le gruik avec les ressources allouées au près de X ? (tu sais, celles qu'il oublie de désallouer en quittant)

            Personnellement, je ne suis pas forcément contre ce genre de fonctionnalité (même si je ne serais pas amené à les utiliser, principalement parce que je n'ai pas de compte gmail par exemple). Mais si c'est pour avoir un logiciel de plus en plus buggé, de plus en plus lourd, et avec des fuites mémoires de plus en plus grosses, non merci.

            • [^] # Re: Gmail offline

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              C'est chiant ces complaintes à répétition à propos des leaks and co. Et c'est encore plus chiant de voir ces suppositions de fuites mémoires sur des choses que tu n'as même pas encore testé.

              Les devs Mozilla y travaille dur sur ces problèmes, qui ne sont pas évident à résoudre vu la complexité du code. M'enfin dans Firefox 3, les choses devraient s'améliorer car de nombreuses améliorations ont été fait en ce sens, notamment l'intégration d'un cycle garbage collector &cie, la deCOMtamination de certains objets du coeur (ce ne sont plus des XPCOM, mais ça je dirais que ça améliore plus la performance que corriger des leaks ) etc..

              • [^] # Re: Gmail offline

                Posté par  . Évalué à -1.

                C'est chiant ces complaintes à répétition à propos des complaintes à répétition sur les leaks and co. Et c'est encore plus chiant de voir qu'on nous fait dire des choses qu'on a pas dit. C'était une question. Quand je vois comment la consommation mémoire à fortement augmenté entre la 1.5 et la 2.0... Et vu les echo que j'ai de ceux qui ont déjà testé la branche de la futur 3.0... J'ai de forte raison de m'inquiéter oui.

                Faire un break dans l'implémentation de nouvelles fonctionnalités pour se concentrer uniquement sur ces problèmes seraient une très bonne chose je pense. Ça au moins ça serait un gros pas en avant, beaucoup plus que d'avoir un meilleur gestionnaire de marque-pages, ou de pouvoir consulter son compte en état hors-ligne (ce qui augmentera forcément l'utilisation de la mémoire, tu ne peux le nier).

                • [^] # Re: Gmail offline

                  Posté par  (site web personnel, Mastodon) . Évalué à 3.

                  > C'était une question.

                  Désolé, mais je l'ai lu comme une supposition. Comme ta phrase ci dessous d'ailleurs : tu supposes qu'ils ne font rien à ce propos alors que c'est faux. En ce qui concerne les retours sur FF3, cela ne t'auras pas échappé qu'il n'en est encore qu'au stade alpha, et qu'il est alors bien imprudent d'annoncer quelconque malfaçon comme tu le fais ci-présent.

                  >Faire un break dans l'implémentation de nouvelles fonctionnalités pour se concentrer uniquement sur ces problèmes seraient une très bonne chose je pense.

                  Il y a pratiquement des personnes qui ne font que ça. Et franchement, je ne vois pas en quoi les deux types de développements (optimisations/newfeatures) serait incompatibles. De toute façon, il y a des corrections de bugs qui nécessitent des compétences spécifiques que n'ont que très peu de personnes. Alors pendant que les personnes concernées corrigent les bugs/leaks profonds, les autres devs (payés ou bénévoles) font quoi ? ils se tournent les pouces ?

    • [^] # Re: Gmail offline

      Posté par  . Évalué à 2.

      L'intérêt, c'est la fonctionnalité n° 1 de gmail : la publicité ciblée.
      Un client mail classique est beaucoup trop anonyme pour Big brother Google ...

  • # Inadmissible !

    Posté par  . Évalué à 3.

    Ça ne fonctionne pas non plus sous lynx/w3m/links, c'est quand même incroyable ! :)

  • # Konqueror recoit ce qu'il cherche

    Posté par  (site web personnel) . Évalué à -2.

    Konqueror a besoin de KDE pour fonctionner, qui ne fonctionne que sous Linux (pour le moment)

    Du coup, peu de part de marché, nerf de la guerre, du coup c'est à lui de s'adapter.
    C'est comme ça, la notion de part de marché pour être incontournable est nécessaire.
    L'équipe de Konqueror a fait un choix, faut assumer. (Idem pour Safari sous Mac!)

    Et quelqu'un peut-il me rassurer en disant que à partir du moment où un navigateur gère correctement les standards du web (HTML, CSS, EcmaScript), il n'aura pas de problème ?

    aucun navigateur étant 100% compatible, faut tous les supprimer?
    Faut en utiliser aucun? hum...
    Les navigateurs s'approchent un maximum des standarts, mais ne sont pas le standards.

    • [^] # Re: Konqueror recoit ce qu'il cherche

      Posté par  . Évalué à 8.

      peu de part de marché, nerf de la guerre, du coup c'est à lui de s'adapter.

      C'est justement ceci le coeur de la promotion des standards du Web, avoir des standards qui ne dépendent en aucun cas de la part de marché d'un navigateur. Ce ne sont pas des standards de fait dûs à un monopole.

      • [^] # Re: Konqueror recoit ce qu'il cherche

        Posté par  (site web personnel) . Évalué à 3.

        Moui, standard ne veut pas non plus dire "implémenté". Il y a de nombreux standards web pas pris en compte par konqueror. S'ils venaient a être utilisé,tu hurlerais de la même façon;

        Voici quelques standards non pris en compte (à ma connaissance) :
        XSLT - MathML - XForms - RSS/ATOM - VoiceXML - WML - XPath

      • [^] # Re: Konqueror recoit ce qu'il cherche

        Posté par  (site web personnel) . Évalué à 1.

        Tu vis sur quelle planète?
        Je vais adapter ta phrase à la réalité : avoir des standards qui ne dépendent en aucun cas le moins possible de la part de marché d'un navigateur.

        tu peux faire toutes les théories que tu veux, la réalité est la : on (le développeur d'une entreprise pour qui ça a un cout) s'en fou que ça ne marche pas sous Konqueror, tant que ça marche sous IE et FF (et à la limite Safari, ce qui porte a 99% le taux de personne pouvant y accéder).

        De plus, qui te dis que ce n'est pas Konqueror qui a un bug? Konqueror n'est pas connu pour être 100% conforme (comme tous les autres navigateurs), tu accuses le code de Google, mais pourquoi ne pas accuser le code de Konqueror?

        • [^] # Re: Konqueror recoit ce qu'il cherche

          Posté par  . Évalué à 4.

          Je n'accuse pas Google du tout, j'ai dû mal me faire comprendre. La fondation Mozilla, les représentants de Safari et de MS se sont mis d'accord sur le développement de nouvelles fonctionnalités à propos de ce mode hors ligne. Ces discussions ont eu lieu en dehors des organismes officiels de promotion de standards, donc des débats où personne de la communauté comme les développeur KHTML ou ceux d'Opéra (à confirmer) n'a pu participer pour fournir un standard.

          C'est une attitude très différente de ce qu'il y avait auparavant. Si un navigateur ne supportait pas bien un standard, c'est lui qui était en tord. Si par contre, les développeurs de navigateurs ayant une forte part de marché décident dans leur coin d'adopter des fonctionnalités non standards sans communiquer sur ses fonctionnalités ou les proposer comme standard, tous les autres navigateurs se retrouvent le bec dans l'eau.

          • [^] # Re: Konqueror recoit ce qu'il cherche

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Si mozilla et consort ont fait leur truc dans leur coin, c'est bien parce que le W3C est une organisation lourde pour pondre un standard. Et dans un WG du W3C, il y a souvent trop de monde, donc trop de consensus, trop de compromis. Résultat : ça a du mal à avancer.

            De plus, pour qu'une recommandation du W3C soit validée, il faut une implémentation du truc. Or il y a des cas où l'implémentation est très difficile (cf certaines propriétés css2), ou possible mais industriellement pas utilisable.

            Alors voilà, Mozilla, Opera, Apple ont préféré faire un truc ensemble dans leur coin (le fameux WHATWG), afin d'avancer le plus rapidement possible et proposer des features qui répondent *vraiment* aux besoins des développeurs web actuels. (D'ailleurs le W3C a pris peur et a fini par créer les groupes de travail appformat, webapi ...)

            MAIS, cela ne veut pas dire qu'ils vont en rester là. Parce que l'objectif final est tout de même de proposer leurs spécifications au W3C, avec, pour quelques unes d'entres elles, des implémentations qui fonctionnent et qui montrent que les specs pondues, ce n'est pas que des trucs tordues sortis tout droits de la tête de savant fous.

            D'ailleurs parmis les specs proposées au W3C, il y a déjà la spec xmlHttpRequest et XBL2 qui sont sur le point de passer en recommandation...

            • [^] # Re: Konqueror recoit ce qu'il cherche

              Posté par  . Évalué à 3.

              Merci pour ces explications. Ca veut pas dire que j'approuve, bien sûr, mais au moins c'est plus clair.
              Personnellement, je ne suis pas d'accord du tout avec le fait qu'il y ait besoin de nouveautés tellement urgentes pour les applis web et ça vaut le coup d'avancer avec le W3C, m'enfin bon, qui suis-je sinon un simple utilisateur ?

              • [^] # Re: Konqueror recoit ce qu'il cherche

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                ba demande aux developpeurs web 2.0 ce qu'ils en pensent de toutes ces nouveautés ;-) C'est pas tant une question d'urgence, qu'une question d'avancer. Il FAUT faire évoluer la plateforme web, si on ne veut pas que les applications web migrent vers des trucs proprio comme silverlight ou flash/apollo. Car il est clair que si la plateforme web ne répond pas aux besoins des développeurs, ils finiront par migrer vers d'autres technos, d'autres plateformes (vers toujours plus de facilité, de possibilité etc..)

                Bref, finalement si, c'est une urgence.

                Et en tant que simple utilisateur, tu as aussi à y gagner : des applis/sites mieux conçu, plus légèrs, offrant plus de possibilité etc...

                • [^] # Re: Konqueror recoit ce qu'il cherche

                  Posté par  . Évalué à 2.

                  Je ne suis pas convaincu personnellement, mais je vois ce que tu veux dire. Le truc, c'est que le navigateur Internet va devenir une vraie usine à gaz mouvante nécessitant toujours plus d'innovation. Je ne vois pas comment les navigateurs comme Konqueror vont faire pour suivre le rythme et je ne vois pas de mouvement pour une meilleure intégration Firefox-KDE. Je ne vois pas non plus comment ferait un primo-arrivant sur le marché du navigateur. Bref, le mouvement est vers un verrouillage du marché vers ceux qui en ont les moyens. Je pense qu'on aurait pu se passer de cela.

                  • [^] # Re: Konqueror recoit ce qu'il cherche

                    Posté par  (site web personnel, Mastodon) . Évalué à 2.

                    devenir une usine à gaz ? non du moment que ce qu'il propose est réèllement utilisé et bien implémenté. C'est pas parce qu'il y a plein de fonctionnalités que c'est une usine à gaz.

                    Pour le suivi du rythme et en ce qui concerne Konqueror : trés honnetement, si apple n'avait pas pris khtml comme moteur, il ne serait pas là où il en est, même avec toute les bonnes volontés de l'équipe khtml. Les grandes avançées dans le moteur Khtml sont dues aux developpements qu'ont fait les devs d'apple, si je ne raconte pas de bêtises. Mais ce n'est pas forcément négatif. Apple fait parti du WHATWG, donc en principe implémentera toutes les nouvelles features liées au moteur dans webkit, que pourront alors reprendre les devs de khtml pour intégrer dans Konqueror. Je ne pense donc pas que les jours de Konqueror soient comptés.

                    Pour une meilleure intégration de Firefox dans KDE, faudrait que quelqu'un travaille sur l'intégration de qt comme toolkit dans Gecko. Il fut un temps où ça marchouillait, mais je crois que c'est un peu à l'abandon de ce coté là effectivement. http://lxr.mozilla.org/seamonkey/source/gfx/src/qt/
                    http://lxr.mozilla.org/seamonkey/source/widget/src/qt/ (et il faudrait travailler sur d'autres composants pour mieux communiquer avec KDE, genre le clipboard, le wallet etc)

                    >Je ne vois pas non plus comment ferait un primo-arrivant sur le marché du navigateur.

                    Si tu remarques bien, ce fait n'est pas nouveau. depuis combien d'années il n'y a pas eu de "grand" navigateur ? Ou plutôt de nouveau moteur de rendu web utilisé par un des principaux navigateurs ? pas loin de 10 ans ? (le dernier doit être khtml non ? et ça fait combien d'années qu'il a débuté ce projet ?)

                  • [^] # Re: Konqueror recoit ce qu'il cherche

                    Posté par  . Évalué à 1.

                    c'est que le navigateur Internet va devenir une vraie

                    @#§! navigateur web !

    • [^] # Re: Konqueror recoit ce qu'il cherche

      Posté par  . Évalué à 5.

      Konqueror a besoin de KDE pour fonctionner, qui ne fonctionne que sous Linux (pour le moment)

      C'est faux, il y a aussi d'autres OS. Par exemple, FreeBSD et PC-BSD. Par compte, ça ne fait pas significativement monter les parts de marché, ça, c'est sur ;-)

  • # Google Developer Day

    Posté par  . Évalué à 3.

    Je suis justement au GDD a San Jose (ca aurait du etre au Googleplex mais il y avait trop de monde...) et ils parlent beaucoup de Google Gears. Si quelqu'un est assez rapide pour poster ici je peux transmettre les questions et rapporter les reponses.

    1. C'est open source (BSD-like)
    2. Ca se base effectivement sur HTML et Javascript, de facon a pouvoir adapter un service web existant facilement
    3. Ca marche pour Firefox, IE, Safari ; ils bossent avec Opera pour sortir un plug-in
    4. Ils veulent le promouvoir comme standard

    Techniquement, il y a 3 elements:
    1. LocalServer: un systeme de cache des pages HTML, Javascript et les images
    2. Une base de donnees SQLite locale, pour cacher les donnees localement (et en bonus offre l'indexation en texte integral)
    3. Le "Workpool", pour faire des traitements couteux en Javascript en tache de fond sans bloquer l'interface (un peu comme des threads, mais c'est pas des threads)

    Le code est la: http://code.google.com/p/google-gears/source

    C'est deja assez generique : il y a beaucoup de code partage entre les differents navigateurs (IE, FF et Safari), donc je ne pense pas que ce soit tres dur d'ajouter le support pour Konqueror. Le plus gros du code est du code natif, il y a peu d'UI, et ca tourne sous Linux puisque FF Linux est supporte. Il faut juste ajouter le boilerplate pour en faire un plugin Konqueror.

    Bref, ceux qui veulent Google Gears pour Konqueror n'ont qu'a se mettre au boulot ! On peut pas dire que Google les empeche de le faire.

  • # Bonne idée à la base ???

    Posté par  . Évalué à 0.

    C'est quoi l'interet d'utiliser une techno de communication pour faire de la bureautique ? La multiplication des couches pour faire ramer le tout toujours plus ? L'absence de standard completement implémenté de rendu pour être sûr d'obtenir des résultats légèrement ou complètement différents d'une machine à l'autre ? Donner du boulot aux dev de mozilla ? :p

    • [^] # Re: Bonne idée à la base ???

      Posté par  (site web personnel) . Évalué à 2.

      Au hasard : répondre au besoin de l'utilisateur, quel qu'il soit, sur quoi (OS, Deskstop manager...) qu'il soit, ou (chez lui, au cyber-café, perdu dans la montagne...) qu'il soit, et ce le plus rapidement possible?

      • [^] # Re: Bonne idée à la base ???

        Posté par  . Évalué à 2.

        J'ai surtout l'impression qu'on essaie de refaire un OS complet au dessus du navigateur avec une API commune...
        Ce qui me rappelle furieusement OpenStep (l'API commune), mais en plus lourd et moins bien...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.