Le contexte:

Le projet a pour but d'améliorer l'ergonomie et l'usabilité du back office d’un produit en cours de développement réalisé en collaboration avec SFEIR

Dans le cadre de ce projet, la version de GWT utilisée passe de la 1.7.1 à la 2.0.3 afin de bénéficier des nouvelles fonctionnalités offertes par cette version. De nouveaux pattern de développement ont également été mis en place au cours de ce projet.

Voici une série d'article sur les nouveautés de GWT 2, les choix d'architectures, et bibliothèques utilisés qui font part de notre retour d'expérience sur le sujet. Ces articles ont été écris par David Aboulkheir, Patrice de Saint Steban et Cyril Lakech

1. Nouveautés de GWT 2.0
2. UiBinder, enfin une forte collaboration entre le designer et le développeur
3. Intégration facile de maquette Html en GWT 2
4. Architecture Modèle-Vue-Presenteur
5. Implémentation Modèle-Vue-Présenteur
6. Ecrire des tests unitaires avec Mockito
7. Mise en place de Gin sur le projet
8. Internationalisation

UiBinder, enfin une forte collaboration entre le designer et le développeur

Dans la version 2 de GWT, Google propose aux développeurs de choisir comment coder les écrans, soit en Java uniquement comme c'était le cas jusqu'à présent soit en utilisant une nouvelle fonctionnalité UiBinder, qui permet de coder les écrans en XML, très proche du HTML.

UiBinder permet d'écrire les interfaces graphiques avec un formalisme XML un peu comme on peut le faire avec JSF, Flex, Silverlight ou encore en HTML. Jusque-là, la création d'interface en GWT se faisait en manipulant du code java à la façon native de Swing ou SWT/JFace. On va maintenant pouvoir les écrire en XML et les lier (les binder) avec une classe java qui contiendra le code de notre vue. Le code en sera d'autant plus lisible, maintenable et plus rapide à développer. Cette évolution va permettre également la multiplication d'outils puissants, comme les éditeurs d'interfaces GWT, plus simples à créer, comme GWTDesigner d'Instantiations, qui a été acheté par Google et qui est maintenant disponible gratuitement: http://code.google.com/intl/fr/webtoolkit/tools/download-gwtdesigner.html

Cette nouvelle organisation, sépare la partie présentation (l'écran) de la partie contrôle (le code java). On écrit un fichier XML contenant nos widgets graphiques, puis on les associe avec les objets dans notre classe java où l'on ajoute aussi les évènements de l'IHM. Il est également possible d'écrire notre interface en HTML en y incorporant nos widgets HTML. Le CSS peut se trouver directement dans le fichier d'interface ou dans un ClientBunddle (système GWT2 de gestion des ressources type CSS en java qui sera détaillé ci-dessous).

Prenons une classe Miniature.java, qui permet d'afficher une image et son titre, pour utiliser UIBinder. Commençons par créer le fichier xml :

<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
xmlns:gwt='urn:import:com.google.gwt.user.client.ui'>
<ui:style>
   .mini {
    float : left;
    margin: 20px;
    height: 150px;
    width: 150px;
   }
</ui:style>
   <gwt:VerticalPanel styleName="{style.mini}">
        <gwt:Image ui:field="miniature" />
       <gwt:Label ui:field="label"/>
   </gwt:VerticalPanel>
</ui:UiBinder>

Nous voyons ici, que la racine du XML, ui:UiBinder permet de configurer les namespaces pour utiliser les composants, le namespace "ui" contient les configurations du UiBinder, tandis que le namespace "gwt" permet d'utiliser les composants de base de GWT. La balise <ui:Style> permet d'insérer le CSS utilisé par notre composant. Dans la suite du fichier, on peut accéder à la classe CSS en utilisant la syntaxe {style.nomClasse}. Nous voyons ensuite que le composant GWT racine est le VerticalPanel qui contient une Image et un Label. Pour les composants Image et Label, on a ajouté un attribut ui:field associé à un nom de paramètre, ce qui nous permettra d'accéder au composant depuis notre classe Java.

Voyons maintenant la classe Java associée :

public class Miniature extends Composite {
    interface Binder extends UiBinder<Widget, Miniature> { }

    private static final Binder binder = GWT.create(Binder.class);
    @UiField Image miniature;
    @UiField Label label;
    private String destination;

    public Miniature(String url, String titre, String destination) {
        this.destination = destination;
        initWidget(binder.createAndBindUi(this));
        miniature.setUrl(url);
        label.setText(titre);
    }

    @UiHandler("miniature")
    public void onClick(ClickEvent event) {
        Window.open(destination, "Image", "width=200, height=100");
    }
}

L'interface Binder étend UiBinder qui prend deux paramètres de type, le composant de base de notre interface (VerticalPanel dans notre cas, mais nous utilisons une super classe), et la classe qui va contenir les composants reliés (La classe actuel). Nous créons ensuite, en variable static, une instance de cette interface en utilisant GWT.create(); C'est le compilateur de GWT qui s'occupera d'implémenter cette classe en utilisant les informations du fichier XML.

Puis nous ajoutons les champs de notre interface en utilisant l'annotation @UiField pour indiquer à GWT qu'il faut relier ces champs avec les composants GWT définis dans le fichier XML. Le nom du champ doit être celui donné dans l'attribut ui:field. Dans notre constructeur, nous appelons la methode createAndBindUi sur notre interface Binder, qui va alors créer et relier les composants GWT à notre classe. Enfin, la methode onClick, appelée lors du clic sur l'image, est reliée à notre composant miniature grâce à l'annotation @UiHandler("miniature").

UiBinder permet aussi de créer une interface en HTML et d'y intégrer nos composants GWT sans passer par les traditionnels composants Panel de GWT (VerticalPanel, Grid, ...), tout simplement en utilisant le composant HTMLPanel. Utilisons ce procédé pour refaire le formulaire de recherche :

<?xml version="1.0" encoding="UTF-8"?>
<ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:gwt='urn:import:com.google.gwt.user.client.ui'>
    <ui:style>
        .label {
            float: left;
            width: 50px;
            clear: both;
        }
        .element {
            float: left;
            width: 250px;
        }
</ui:style>
    <gwt:HTMLPanel>
        <dl>
            <dt class='{style.label}'>
                <ui:msg>Topic :</ui:msg>
            </dt>
            <dd class='{style.element}'>
                <gwt:TextBox ui:field="saisieSujet" />
            </dd>
            <dt class='{style.label}'>
            </dt>
            <dd class='{style.element}'>
                <gwt:Button ui:field="boutonAjouter">
                    <ui:msg>Search</ui:msg>
                </gwt:Button>
            </dd>
        </dl>
    </gwt:HTMLPanel>
</ui:UiBinder>

Ici, la classe Java est sensiblement équivalente à la classe Miniature.java :

public class FormulaireRecherche extends DialogBox {
    interface Binder extends UiBinder<Widget, FormulaireRecherche> {}
    private static final Binder binder = GWT.create(Binder.class);

    @UiField Button boutonAjouter;
    @UiField TextBox saisieSujet;

    public FormulaireRecherche() {
        super(true);
        add(binder.createAndBindUi(this));
        center();
    }

    @UiHandler("boutonAjouter")
    public void onClick(ClickEvent event) {
        hide();
    }
}

Références :

• http://code.google.com/intl/fr/webtoolkit/doc/latest/DevGuideUiBinder.html
• http://www.programmez.com/magazine_articles.php?titre=GWT--comment-ca-marche--4e-partie&id_article=1307&magazine=125

Il y a un peu plus d'une semaine, Google annonçait la sortie de Google Chrome Frame.
Vous en avez surement déjà  beaucoup entendu parler.

Pour rappel, il s'agit d'un plugin s'intégrant à Internet Explorer et permettant de bénéficier
du moteur de rendu de Google Chrome, lui même basé sur WebKit.

Chrome Frame ne vient pas complètement remplacer le moteur de rendu d'Internet Explorer, il ne prend la main que si l'utilisateur ou la page qu'il visite le demandent explicitement.

Si vous souhaitez spécifier que votre page doit être chargée par Chrome Frame, il vous suffit de rajouter la balise suivante :

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Sur le plateau de développement où je suis actuellement en mission, nous développons des applications GWT. Il s'agit d'applications de gestion dont les traitements côté client peuvent parfois être assez importants. La fluidité sous Internet Explorer n'est donc souvent pas optimale quand on la compare à celle sous Firefox ou Chrome.

Malheureusement, comme dans de nombreuses entreprises, le navigateur installé sur les postes de nos utilisateurs est Internet Explorer et faire installer un second navigateur pour optimiser la consultation de nos applications n'est pas vraiment une possibilité.

A l'annonce de la mise à disposition de ce plugin, nous avons décidé de le tester sur nos applications et les résultats se sont montrés vraiment impressionnants. Les gains en termes de rapidité d'exécution et de fluidité sont tels que l'adoption a été quasiment immédiate par le client.
Certes, tout n'est pas rose, nous avons eu quelques petites surprises d'affichage et le plugin est encore très jeune mais globalement pour un effort vraiment minime, les gains en termes de performance sont au-delà de ce que n’importe quelle optimisation de notre application aurait pu donner.

Le site officiel de Google Chrome Frame
L'annonce sur le site de GWT
Chrome Frame et Google Wave

Google a trouvé un moyen très efficace d’imposer son navigateur. Un petit site très sympa proposant un tas de démos plus impressionnantes les unes que les autres et… nécessitant Chrome bien sûr. En effet elles reposent toutes ou presque sur le HTML 5 Canvas qui n’est pas supporté par tous les navigateurs avec la même fidélité.

Il s’agit ni plus ni moins d’une publicité comparative. Le site est là pour comparer les moteurs javascripts des différents navigateurs et c’est Chrome qui obtient les meilleurs résultats. Bien sûr, le site affiche son affinité. Mais force est de constater l’efficacité de la chose. Et puis c’est quand même plus drôle qu’une série de graphiques comparatifs.

Le site sort le même jour que le nouveau navigateur de Microsoft, IE8. La guerre est ouverte. Alors même qu’elle semble relancée entre Apple et Microsoft. Google tenterait-il d’en profiter ? Quand les arguments entre Mac et PC ne varient pas : “ils sont trop chers” contre “ils nous pillent”. Google apportera-t-il un peu de fraîcheur ? En tout cas on ne va plus savoir où donner de la tête.

Ces arguments semblent avant tout montrer que c’est la crise pour tout le monde. Quand il y avait de la place pour tous, les arguments étaient moins trash. Maintenant, on ne va pas bouder son plaisir, ces petites campagnes de pub comparatives à l’américaine sont assez drôles en général. C’est déjà ça.

On attend avec impatience le match MacOS/Windows 7. Alors, à quand l’OS Google sur PC ?

En tout cas de bons moments de rigolades en perspective (je parle du site bien sûr). Et à tester avec vos enfants bien sûr.

Le site à visiter absolument : http://www.chromeexperiments.com/

La dernière version snapshot de Guice intégre des fonctionnalités intéressantes pour les Servlets, notamment de nouveaux Builders qui viennent du projet warp-servlet et qui permettent de configurer des mappings de Servlet ou de Filter directement dans un module. Vous pouvez obtenir les sources de l’exemple décrit dans cet article ici.

Au lieu de définir nos RemoteServiceServlet dans le web.xml (ce qui est désormais le cas avec GWT 1.6), nous allons déclarer un GuiceServletContextListener et un GuiceFilter :

 1 <?xmlversion="1.0"encoding="UTF-8"?>
 2 <web-app>
 3 

 4 <!-- Default page to serve -->
 5 <welcome-file-list>
 6  <welcome-filecda.html</welcome-file>
 7 </welcome-file-list>
 8 

 9 <listener>
10  <listener-classcom.sfeir.server.CdaGuiceServletConfig
11  </listener-class>
12 </listener>
13 

14 <filter>
15  <filter-nameguiceFilter</filter-name>
16   <filter-classcom.google.inject.servlet.GuiceFilter
17  </filter-class>
18 </filter>
19 

20 <filter-mapping>
21  <filter-nameguiceFilter</filter-name>
22  <url-pattern/*</url-pattern>
23 </filter-mapping>
24 

25 </web-app

GuiceServletContextListener crée une instance d’Injector avec la méthode getInjector(), nous pouvons alors définir notre module en redéfinissant cette méthode :

 1 public class CdaGuiceServletConfig extends GuiceServletContextListener
 2 {
 3     @Override
 4     protected Injector getInjector()
 5     {
 6         return Guice.createInjector(new ServletModule()
 7         {
 8             @Override
 9             protectedvoid configureServlets()
10             {
11                 serve("/cda/echo").with(EchoServiceImpl.class);
12                 serve("/cda/spreadsheet").with(SpreadSheetServiceImpl.class);
13 ...

Nous utilisons pour cela une classe anonyme qui hérite de ServletModule : les méthodes «serve» et «filter» de cette dernière nous permettent de faire l’équivalent de huit lignes de XML pour déclarer une Servlet ou un Filter en une seule ligne de Java.

«serve» fonctionne directement avec les RemoteServiceServlet de GWT (il faut néanmoins ajouter y l’annotation Singleton), par contre les scopes Session et Request de la classe ServletScopes ne peuvent pas être utilisés : nous allons devoir hériter de la classe RemoteServiceServlet pour y ajouter notre propre Scope Session et par la même occasion ajouter un champ «injector» qui contiendra l’objet Injector créé par notre classe CdaGuiceServletConfig.

Dans notre ServletModule, nous rajoutons un appel à «bind» qui associe l’interface SpreadsheetManager à une implémentation :

 1                 bind(SpreadsheetManager.class).
 2                         to(SpreadsheetManagerImpl.class);

Ainsi l’appel de getInstance de l’object Injector avec SpreadsheetManager.class en paramètre renverra une instance de SpreadsheetManagerImpl.

 1 @Singleton
 2 public class SpreadSheetServiceImpl extends GuiceRPCServlet implements SpreadSheetService
 3 {
 4 

 5     @Override
 6     public List<String> fetchSpreadsheetList()
 7     {
 8         SpreadsheetManager manager = injector.getInstance(SpreadsheetManager.class);
 9         ...

Par défaut, l’Injector de Guice renvoie toujours une nouvelle instance. Nous pouvons également utiliser l’annotation Singleton ou dans le cas présent notre propre annotation GwtSessionScoped afin qu’une même instance soit réutilisée, par exemple le temps d’une session.

 1                 bindScope(GwtSessionScoped.class,
 2                         GuiceRPCServlet.SESSION);
 3                 bind(GoogleService.class).toProvider(
 4                         SpreadsheetServiceProvider.class).
 5                         in(GwtSessionScoped.class);

Ainsi les champs injectés de type GoogleService seront créés une première fois puis récupérés dans la session en cours. Ce mécanisme fonctionne quand l’Injector de Guice est appelé, il est donc exclu de l’utiliser sur des champs d’une RemoteServiceServlet.

 1 public class SpreadsheetManagerImpl implements SpreadsheetManager
 2 {
 3     @Inject
 4     private GoogleService service;
 5 

 6     @Inject
 7     @Named("user")
 8     private String username;
 9     @Inject
10     @Named("pass")
11     private String password;
12 

13     @Override
14     public void authenticate()
15     {
16         try
17         {
18             service.setUserCredentials(username,password);
19         } ...

L’annotation Named est utile pour injecter objets de même type sans avoir à créer de nouvelle annotation. La méthode statique «named» crée cette annotation pour l’utiliser dans les instructions de binding.

 1                 bindConstant().annotatedWith(named("user")).
 2                         to("cappelle.florent@gmail.com");
 3                 bindConstant().annotatedWith(named("pass")).
 4                         to("*************");

Finalement, Guice permet aussi d’ajouter des fonctions transverses à nos services en «bindant» un intercepteur sur un ensemble de méthodes :

 1                 bindInterceptor(subclassesOf(SpreadsheetManager.class),
 2                         returns(subclassesOf(List.class)),
 3                         new LoggingInterceptor());

Ici, LoggingInterceptor est appliqué aux classes qui héritent de SpreadsheetManager et plus particulièrement aux méthodes de ces classes dont le retour est de type List. Les classes d’interception doivent implémenter MethodInterceptor de l’API aopalliance.

Vous aurez sans doute deviné que LoggingInterceptor fait un log des appels de méthode, la sécurité et les transactions étant les autres exemples typiques d’utilisation des MethodInterceptor.

En conclusion, Google Guice constitue une alternative intéressante à Spring pour l’injection de dépendance. Dans certains cas, on pourra également utiliser les méthodes de la classe SpringIntegration afin de réutiliser une configuration XML existante.

Liens :

• Sources de l’exemple : ici.
• Guice : http://code.google.com/p/google-guice/downloads/list
• GWT 1.6 M1 : http://code.google.com/p/google-web-toolkit/downloads/list?can=1&q=1.6.0

While the Java client library for Google DATA API can’t be compiled by the GWT compiler, you can still use it in RPC Servlets with the advantage of hiding the protocol or substituting the default authentication backend with yours.

The screenshot below shows an example of a simple GWT application made up of a tree widget displaying my spreadsheets and their worksheets, and a grid widget on which appears the selected worksheet.

The source code of this demo is at the bottom.

Google Data APIs are based on Atom and RSS formats and the Atom Publishing Protocol. Since they are REST-styled, you may use them with any browser:

First we need to authenticate to the service we want to use (Google Spreadsheets in our case) with our Google account. The easiest way is to use the ClientLogin interface:

$ export TOKEN=`curl https://www.google.com/accounts/ClientLogin \
-d Email=cappelle.florent@gmail.com -d Passwd=$GDATA_PASSWORD \
-d accountType=HOSTED_OR_GOOGLE \
-d source=SFEIR-GWTSheets-1 \
-d service=wise | grep 'Auth=' | cut -d'=' -f2`

The service parameter is the Google service we want to use; in this case the «wise» value stands for the spreadsheets service. If the login is successful, the response will include a token which we will use in the next requests. Note that in some cases the service may require a CAPTCHA challenge to be done.

Then we request the list of the spreadsheets we include our token in the Authorization header:

$ curl -H "Authorization: GoogleLogin auth=$TOKEN" \
"http://spreadsheets.google.com/feeds/spreadsheets/private/full" > SpreadsheetList.xml

Querying and editing our spreadsheets this way (you would have to build PUT requests with XML) would be quite inefficient. Instead of parsing XML and building HTTP requests, you may use the Java client library which already does this for you with the SpreadsheetService class:

  1         SpreadsheetService sService;
  2         sService = new SpreadsheetService("SFEIR-GWTSheets-1");
  3         try
  4         {
  5             sService.setUserCredentials(email, password);
  6             logger.info(email + " authentication successful");
  7             getSession().setAttribute("sService", sService);
  8         } catch (AuthenticationException e)
  9         {
 10             logger.log(Level.WARNING, e.getMessage());
 11             thrownew AuthException(e.getMessage());
 12         }

The preceding piece of code is extracted from a GWT-RPC Service method:

• The «setUserCredentials» method requests a token and stores it in the sService object, which we store in the session for the next requests.
• If the login fails or a CAPTCHA challenge is needed, an AuthException is thrown back to the client.

Once the user is logged in, we build a feed URL with the FeedURLFactory class (see the following piece of code). Its «getSpreadsheetsFeedUrl» returns the URL for the spreadsheet list feed, which then is fetched by the SpreadsheetService object (sService).

  1         List<SpreadsheetEntry> spreadsheetEntries = null;
  2         FeedURLFactory factory = FeedURLFactory.getDefault();
  3         SpreadsheetFeed feed;
  4
  5         try
  6         {
  7             feed = service.getFeed(factory.getSpreadsheetsFeedUrl(),
  8                     SpreadsheetFeed.class);
  9             spreadsheetEntries = feed.getEntries();
 10             getSession().setAttribute("spreadsheetEntries",
 11                     spreadsheetEntries);
 12         } catch (IOException e) ...

The «getEntries» method returns a list of SpreadsheetEntry: Each of these entries contains standard Atom information (author, title, etc) and a worksheet list feed URL. However we don’t even need to build a feed URL since the «getWorksheets» method directly returns a list of WorksheetEntry.

The SpreadSheetModel is a list of Worksheet which is returned to the GWT client: the title and the dimensions of each worksheet are used by the tree and the grid widgets. The cell feed URL is also needed to fetch the content of each cell.

  1         SpreadSheetModel model = new SpreadSheetModel();
  2         try
  3         {
  4             List<WorksheetEntry> worksheetEntries =
  5                     entry.getWorksheets();
  6             for (WorksheetEntry sheet : worksheetEntries)
  7             {
  8                 model.add(new SpreadSheetModel.WorkSheet(
  9                         sheet.getTitle().getPlainText(),
 10                         sheet.getCellFeedUrl().toExternalForm(),
 11                         sheet.getRowCount(), sheet.getColCount()));
 12             }
 13         } catch (IOException e) ...

At the client side, the code that fills the tree widget is pretty simple:

 1             public void onSuccess(SpreadSheetModel model)
 2             {
 3                 TreeItem item = getItem(position);
 4                 for (SpreadSheetModel.WorkSheet sheet : model)
 5                 {
 6                     TreeItem newItem = item.addItem(sheet.getTitle());
 7                     newItem.setUserObject(sheet);
 8                 }
 9                 // remove the empty child (see populate method)
10                 item.getChild(0).remove();
11                 item.setState(true, false);
12             }

Once the user clicks on a worksheet title in the tree, the worksheet feed URL is given to a RPC method «fetchworksheetcells», which returns a list of cells: the Cell class of the Google API can’t be used as it is in the client side, so we have to copy its properties to a DTO class (WorksheetCell). «copyProperties» of the Apache Commons Beanutils library does this in a single line.

  1         List<WorksheetCell> cells = new ArrayList<WorksheetCell>();
  2         try
  3         {
  4             CellFeed feed = sService.getFeed(new URL(sheetFeedURL),
  5                     CellFeed.class);
  6             List<CellEntry> cellEntries = feed.getEntries();
  7             for (CellEntry entry : cellEntries)
  8             {
  9                 Cell cell = entry.getCell();
 10                 WorksheetCell clonedCell = new WorksheetCell();
 11                 BeanUtils.copyProperties(clonedCell, cell);
 12                 cells.add(clonedCell);
 13             }
 14         } catch (MalformedURLException e) ...

Note that worksheet feeds also have a list feed, which enables relational alike manipulation of worksheet data. Insertion, modification and deletion are very easy with the Java client, for example the modification of a cell entry needs two lines of code:

  1     cellEntry.changeInputValueLocal(newValue);
  2     cellEntry.update();

Useful Links:

• Spreadsheets service protocol reference: http://code.google.com/intl/fr-FR/apis/spreadsheets/docs/2.0/developers_guide_protocol.html
• Java client library for spreadsheets reference: http://code.google.com/intl/fr-FR/apis/spreadsheets/docs/2.0/developers_guide_java.html
• ClientLogin authentication reference: http://code.google.com/intl/fr-FR/apis/gdata/auth.html#ClientLogin

Article related downloads:

• Demo : Proto GWTSheets
• Java client library source and (very useful) samples: http://code.google.com/p/gdata-java-client/downloads/list

Il y a quelques temps, nous vous parlions ici même de Google App Engine, un projet de Google permettant  aux développeurs d’héberger leurs applications WEB sur ses infrastructures.

Les applications ainsi déployées bénéficient de la même qualité de service et de la montée en charge que l’on connaît pour des applications telles que Gmail, Google Finance, …
Le programme était officiellement ouvert à près de 10 000 développeurs depuis le début du mois d’avril.

Chez SFEIR, nous avions organisé une petite rencontre pour présenter cette technologie aux personnes le désirant. A cette occasion, Didier Girard avait porté son jeu KeyboardWarrior (application GWT) pour fonctionner sur Google App Engine. Curieux d’étudier la capacité de montée en charge de son application, il a organisé il y a une semaine environ un "load test". Les résultats ont été publiés ici.

Les retours des utilisateurs en termes de disponibilité de l’application sont diverses, aucun problème pour certains, un peu de lenteur pour d’autres. Quoi qu’il en soit l’application a tout de même supporté un pic de près de 23 requêtes par seconde pendant une minute, ce qui est plutôt pas mal pour un hébergement gratuit.

Mercredi dernier, Google a annoncé sur un de ses blogs l’ouverture de Google App Engine à tous, de ce fait vous pourrez bientôt tester et vous faire votre propre idée. Toutefois, avant de vous lancer dans la réalisation de votre première application, vous devriez peut être jeter un œil à quelques articles. En voici quelques uns qui expliquent comment faire en sorte que votre application soit scalable et comment il faut penser les applications pour Google App Engine. En effet certains concepts de cette technologie nécessitent que l’on pense autrement. C’est notamment le cas pour l’API datastore (persistance des données), pour laquelle il faut oublier les concepts des bases de données relationnelles.

Google a également annoncé quelle allait être la politique de prix pratiquée pour l’hébergement d’applications sur Google App Engine. Tout d’abord, l’offre d’entrée reste gratuite avec 500Mb de stockage et assez de bande passante et de CPU pour supporter l’équivalent de 5 millions de pages vues pas mois.

Les tarifs se présentent ensuite ainsi :

-10 à 12 cents par heure de CPU

-15 à 18 cents par GB de données par mois

-11 à 13 cents par GB de bande passante sortante

-9 à 11 cents par GB de bande passante entrante

Cette annonce est accompagnée par la mise à disposition de deux nouvelles APIs, une pour la manipulation d’images et une autre pour gérer un cache afin de diminuer les requêtes du datastore.

Je vous invite à suivre les retours des personnes qui assistent aux Google I/O sur Google App Engine, nous en saurons sûrement plus.

Après l'industrie du disque, moribonde du fait semble-t-il du piratage en masse, les éditeurs ont bien cru voir leur dernière heure venir après les lancements successifs par Google et Microsoft de leurs outils de recherche en ligne bibliographique et surtout de leur volonté affichée de numérisation massives et très ambitieuse.

Un an après le lancement de "Live Search Books", cinq après celui de Google Book Search, où en est-on ? Les peurs persistent. Et pourtant, le résultat commercial ressemble plutôt à un flop.

Microsoft arrête le projet "Live Search Books" seulement 18 mois après son lancement (voir The Chicago Blog). D'une part, Microsoft a suspendu son projet de numérisation massive et compte désormais sur les éditeurs et les librairies, d'autre part il a fermé le site séparé et regroupé son indexation dans le reste de ses résultats de recherche. C'est dommage car l'interface était plutôt sympa et la démarche respectueuse (en accord avec les droits d'auteur, ce qui n'est pas toujours le cas de Google, parfois en procès, en tout cas en débat)

Si le concept vous plaisait vraiment et que vous regrettez la démarche, vous pouvez acheter un book ripper, ça va chercher dans les 3000$ (ah c'est pas un scanner... maintenant, Microsoft en vend peut-être d'occasion ;-) ) et ça vous permet de copier 500 pages de l'heure! Bon courage quand même.

De son côté et après 5 ans, Google Book Search est toujours en version Béta mais continue.

L'utilisateur n'a pas été au rendez-vous. Et pourtant. Et pourtant les moyens mis en oeuvre étaient assez colossaux. Et pourtant les acteurs étaient nombreux et motivés (dont nombre d'universités). Et pourtant la finalité était assez noble : permettre un accès rapide et sûr à un ensemble toujours plus grand d'oeuvres et de textes en tout genre et notamment les plus rares. En somme, l'eldorado pour les chercheurs et autres étudiants (et pas qu'en lettres). C'est quand même autre chose que Wikipédia ! Au fond, c'est presque dommage que les Mormons ne se soient pas intéressés au projet.

Une question me viens comme ça: comment comptaient-ils s'y prendre pour les livres pop-up et les livres dépliants pour enfants ?

Bien entendu je n'ai pas résisté à la tentation, j'ai créé ma bibliothèque virtuelle sur Google Books:

http://books.google.com/books?as_list=BDWRCwGwQ5ISB5oaAsfTrARoUtZiceQw0vh5hGXbxnVWWLqFgTGk&hl=fr

Et là, la déception est tout de même au rendez-vous. En français en tout cas, mon Dieu que c'est pauvre. Pas un livre sur trois de ceux que j'ai lu (sans jeu de mot) qui s'y trouve. Au final, j'ai assez vite baissé les bras.

Restent quelque belles initiatives:

• Internet Archive :  417,000 textes
• Open Library : 13,439,320 livres (mais pas encore beaucoup en français)
• Library Thing : 26,000,000 livres
• Open Content Alliance

Autre tentation à laquelle je ne vais pas résister: jouer avec Dynamic Links de Google (Book Viewability API). Et comme on est joueur ou pas, ça sera avec Silverlight. Peut-être dans un prochain post...