Contradiction 1 avec le site officiel de GWT :

• Le livre conseille, page 174 : "nous vous conseillons vivement d'implémenter vos services avec deRPC".
• Le site officiel indique: "Caution: This library should be considered experimental, but is available as a technology preview for early adopters. Please understand the limitations before using it." (http://code.google.com/intl/fr/webtoolkit/doc/latest/DevGuideServerCommunication.html).

Contradiction 2 avec le site officiel de GWT :

• Le livre précise, page 173 : "performances largement supérieures à RPC 1.0 en réduisant la taille des messages échangés".
• Le site officiel mentionne : "Known limitations : he payload size may be larger, which may be a consideration on slower networks or when there are many RPCs." (http://code.google.com/intl/fr/webtoolkit/doc/latest/DevGuideServerCommunication.html).

Question :

• Est-il trop tôt pour utiliser deRPC ?

Réponse (de Sami) : Oui c'est une très bonne question Dominique. C'est tout l'intérêt du wiki, je pourrais raconter l'histoire de ce chapitre et à la lecture certaines choses sembleront (je l'espère) plus claires.

Lorsque la roadmap de GWT 2.0 a été abordée, il n'était pas prévu que deRPC fasse partie du lot. J'avoue avoir une (petite) responsabilité dans le fait que deRPC ou RPC 2.0 aient été intégrés dans GWT 2. Ce Framework a été développé par Bob Vawter, et le premier commit date de Juillet 2009 (http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/631b8c3177930913/3eb27781c6ab7c7b?lnk=raot). Six mois après le commit initial, personne n'avait réellement eu le temps de se plonger dans le framework de Bob.

A titre perso, j'avais regardé les briques et trouvé ça super. L'idée d'utiliser eval(), de chaîner des CommandSink, de pouvoir hooker très facilement processCall() et surtout la partie sécurité (ClientOracle sérialisé sur disque dans le rpc.log). Bref, je me suis dis "wouah, ce framework est génial mais j'ai l'impression qu'à part Bob, personne ne s'y intéresse. Du coup, lorsque je demande le 19 Octobre à Bruce d'abord, puis à la liste, "Will deRPC ship ?" (http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/ad72b85ef1364ffa/057026def35cb914?#057026def35cb914), tout le monde est étonné. Pour Bruce, à ce moment là, il ne fallait pas le livrer. Pour toutes les raisons que j'ai évoqué précédemment. Pas assez testé, pas de retours, empreinte des messages parfois un peu lourde, etc ... Du coup, il a fait un sondage. Et il se trouve que les deux seuls "grouillos" ;-) à avoir répondu ont été Sven (et son collègue) et moi. Mon enthousiasme a convaincu Bruce qui a finalement décidé de l'intégrer dans GWT 2, notamment pour recueillir des retours. Ce jour là, je me suis vraiment rendu compte que l'avis de la communauté comptait pour l'équipe. Cette décision était loin d'être facile à prendre.

Dans ma situation d'auteur d'un livre censé occuper le terrain pendant au minimum 1 an, j'avais trois solutions :

• occulter deRPC et ne parler que de RPC 1.0
• évoquer deRPC 1.0 et deRPC 2.0
• évoquer deRPC comme si RPC 1.0 n'avait jamais existé

La première solution n'était pas trop tenable d'un point de vue de la perennité du livre. Si dans 3 mois, l'équipe GWT annonce que deRPC est désormais solide, le livre ne sert plus à rien. Le seconde solution n'était pas viable car le chapitre sur l'extensibilité s'appuie sur les briques de RPC. En d'autres termes, si je choisi une des deux technos, j'embarque 60 pages de doc associée. Impossible de couvrir les deux sujets. Surtout que le livre fait à la fin déjà 500 pages.

J'ai donc pris le risque (maîtrisé) de ne pas évoquer du tout RPC 1.0. C'est peut-être quelque chose qu'on peut me reprocher aujourd'hui (et je le conçois très bien) mais vu qu'il existe déjà énormément de doc/livres sur le sujet, je me suis dis qu'il valait mieux faire "comme si" RPC 2.0 était la seule solution. De toute façon, à terme, on le sait bien, ce n'est qu'une question de mois, RPC 1.0 sera remplacé.

Dans un tel contexte, aujourd'hui est-ce viable de partir sur RPC 2 pour des développements ? Tout dépend de vos scénarios d'utilisation en fait. Dans certains cas RPC 2 est plus rapide que RPC 1 et dans d'autres, non. RPC 2 a aujourd'hui des payload assez important, mais contrairement à RPC 1, il utilise la compression gzip. Je suis presque certain que l'équipe GWT n'a pas fait de tests ou de benchmark entre les deux API, c'est une (saine) position défensive. Mais en même temps, quel est le risque ? Passer de RPC 1 à RPC 2 et inversement consiste à changer deux interfaces, rien de plus. Côté serveur, on peut même adopter la démarche Hybride (traitée dans le livre).

En l'état, mon conseil (il vaut ce qu'il vaut) est de ne surtout pas occulter RPC 2. Adopter le, et si vous sentez des problèmes de perf potentiels, rollbackez à RPC 1 sur les appels posant problème.

Mais aujourd'hui la position offficielle de Google est clairement de préférer RPC 1 à RPC 2 pour des problèmes de maturité.

Parfois, il faut être audacieux et savoir prendre des risques. Lorsqu'ils sont maîtrisés, c'est beaucoup simple. Lorsqu'on lira le livre dans 6 mois, il collera parfaitement à l'actualité.

Ma réponse est un peu longue, mais je pense qu'elle est importante. N'hésites pas Dominique, si tu veux avoir plus de précisions.

Précision (de Dominique) : Au départ, je me suis intéressé à deRPC pour essayer de résoudre une erreur "StackOverflow" qui se produit lors d'un appel RPC lorsque la grappe d'objets atteint un certain niveau de complexité, et ce uniquement sous Internet Explorer (constaté sous IE8, pas de soucis avec FireFox ou Safari). Citation du site officiel de GWT : "Client-side deserialization is significantly faster on some platforms and is immune from stack-depth problems on all platforms.".

Dans notre projet, nous utilisons Spring et GWL-SL (http://gwt-widget.sourceforge.net/). Avec ce dernier, nous utilisons la classe GWTRPCServiceExporter qui hérite de RemoteServiceServlet. Pour le moment, il n'existe pas l'équivalent qui hériterait de RpcServlet. Dans notre cas, le passage à deRPC n'est donc pas si simple.

Merci Sami pour toutes ces précisions, et ce livre très utile.

-----------------

Page 174, remplacer "RPCService" par "RpcService", et "RPCServlet" par "RpcServlet", dans le texte et sur le schéma.

-----------------

Page 176, il est écrit que "L'interface asynchrone ressemble ... le premier paramètre est une fonction de rappel (ou callback)"

Pour ma part, j'aurai dit le dernier paramètre de la méthode non ? [Réponse Sami] Oui, ça doit mon côté dyslexique. C'est comme l'Ouest qui est passé à l'Est dans le chapitre CSS Layout :-)

-----------------

Page 182 : tu as écrit le type primitif Char avec une majuscule alors que c'est char 

-----------------

Page 189 : Il est écrit : En effet, les classes Java du package client sont inutiles en production du fait qu'elles sont converties en Javascript.

Si par "client", on entend effectivement "les classes java converties en javascript", effectivement, on n'a pas besoin des .class côté serveur.

En revanche, si on comprend par "client" le package défini dans notre application gwt, ton conseil pourra provoquer des erreurs dans certains cas s'il est pris au pied de la lettre par des débutants. Je pense notamment au cas où dans le package client, on aurait également mis les classes des objets qui circulent entre serveur et client, celles que dans ton livre, tu conseilles parfois de mettre dans un dossier shared. Puisque ces objets transitent, le serveur a bien besoin des .class n'est ce pas ? [Réponse Sami] Très juste. Il faut être précis :-).

-----------------

Page 192 : En première lecture, je croyais que tu avais fais 2 fois reqUrl.substring(4) dans ton exemple. En fait, le premier coup, c'est pour l'affichage. Mais pourquoi avoir enlever "url=" pour le remplacer par "URL = ", c'est juste pour le mettre en majuscule ? Sinon tu aurais pu écrire simplement : System.out.println(reqUrl); Je l'avoue, je pinaille. [Réponse Sami] Oui ce n'est que pour la majuscule, c'est pour ça que je n'ai pas écrit sysout(reqUrl), je voulais insister sur le paramètre URL.