Pourquoi Flash Catalyst (FC) ?

Actuellement, sur Flex Builder (FB), les flexeurs codent d’abord puis à la fin s’évertuent à skinner via css leur « belle appli » toute grise. Or ce n’est pas la bonne façon de faire.
Les designers font l’inverse, on skinne + ergonomie et enchainements d’abord, on valide avec les user finaux et après on ajoute l’accès aux données, et c’est comme ça qu’il faut développer une RIA.
FC est juste une passerelle pour récupérer les écrans (par ex. calques PS) produits par les designers (sous forme FXG, le nouveau format déclaratif lisible d’échange entre les outils de design de la CSuite et FC). Après import du FXG, FC permet de mapper une widget standard (bouton, liste, scrollbar etc…) sur un composant purement vectoriel importé de l’outil CS4 (on dit : ce rectangle est en fait un bouton etc…), d’ajouter les navigation/enchainements/transitions puis on transforme tout ça en du code (déclaratif) importable par FB (i.e. un fichier .FXP = nouveau format de projet FC et FB). FC ne fait que du déclaratif/descriptif en MXML, pas de code.
La séparation visuel / logique est améliorée par Flex 4 : MVC est poussé au niveau du composant. FC permet de créer un skin de composant. FB d’y ajouter la logique AS.
Tiens au fait, les démos ont montré le workflow académique de dev d’une RIA : PS pour les calques (avec parfois l’aide d’AI) , puis export FXG dans FC, puis export FXP dans FB.
Quid de l’outil Flash Pro ?
Bref, pour résumer, Catalyst est un outil passerelle « super designer » qui génère du mxml pour FB.

Nouveautés FB4 : 3 maitres mots : ultra productif, data-centric, intégration design/dev

• package explorer avec des vrais packages sans arborescence pénible
• skinning halo versus sparks (ns mx: vs. s:) (puisque Flex4)
• génération auto de la calback sur le click= »" du tag MXML !
• génération auto des set/getter (enfin !)
• refactoring (rename/move) : enfin !
• templates d’en-têtes (copyright etc..)
• pomme-i ré-indente le code
• flex thèmes
• convertir automatiquement un projet web en Air
• spark recommandé car tire bénéfice des nouvelles fonctionnalités du player 10 mais du coup en dépend
• droit admin nécessaire pour flash player ?! -> flash player admin guide
• mxml = purement visuel donc ce qui ne l’ai pas va dans un tag , par ex. : DateFormatter, http service, remote object
• code private = code enlevé pendant la compilation (par ex. catalyst génère du code private en prévision du roundtrip FB/FC)
• api de dessin disponible dans un tag Graphics (ala degrafa) (composant léger)
  o évidemment pas fait pour du dessin intensif (dans ce cas, privilégier import Illustrator)

• Notion d’état (mx:State) :à l’envers : on part de l’élément et on dit dans quel état il est présent
  o + propriété en fonction du state : syntaxe = nom_prop.nom_etat=valeur
  o + élégant, + lisible, – de code, + support de l’IDE (grise/dégrise en sélectionnant l’état dans une combo)

• layout d’une application a changé : maintenant tag Layout = objet
  o on peut créer son layout : demo de boutons en cercle

• index.html template utilise swfobject
• binding double (two-way)
• rendu textuel = moteur de rendu TextLayoutEngine et TextLayoutFramework (cf. NY Times)
• Dans le mode design FB, new Flash component ou new Flash container (.swf)
• Introspection des services : glisser déposer du service introspécté vers datagrid, form, bouton : on drag/drop le service introspecté vers le widget et ça marche direct. Énorme gain de productivité.
• datapaging généré (coté client et serveur : demo php mais censé marcher aussi avec BlazeDS)
  o au niveau php, reste à coder les requêtes des functions count() et getItems_paged()
  o clic droit enabling Paging -> wizard
  o résultat : charge on demande de la scroll et charge tout en background

• + data management = maîtrise du commit (i.e. qd on veut)
• debug conditionnel
• point d’arrêt au runtime : runtoline() si oublié de mettre un point d’arrêt avant de lancer l’appli
• gestion du mode déconnecté : seulement avec LCDS pour l’instant avec commit différé
• bien comprendre que le passage halo -> spark est gros changement, d’où les évènements préparatifs d’Adobe comme celui-ci.
• blog tontons flexeurs permettra de donner ses idées
• Au fait, Certification Flex nouveau en France, via formation Baao

Conclusion : FC va permettre aux designers de livrer leurs travaux sous forme exploitable par des développeurs Flex. Car – et je l’ai constaté sur un projet récemment – il y a en fossé entre les designers Flash et les développeurs Flex (qui sont grosso modo des développeurs Java). C’est donc une bonne chose, si le workflow design -> dev est respecté.
Le pb est que dans la vraie vie de projet d’entreprise, ce n’est pas évident de faire démarrer des protos RIA directement en sous-traitance d’une agence Web/design. Tous les protos fait en avance de phase ou en avant-vente retomberont dans le schéma « dev Flex puis skinning ». Pour ce qui est de FB4, j’attends avec impatience cette version, il y a une réelle amélioration (ensemble de petites de choses mais surtout l’accès aux données !)

Essayons d’analyser cette situation de manière un peu plus approfondie.

On peut retrouver une position comparable lors du rachat de BEA, qui comportait BEA Workshop dans son portefeuille. Une roadmap avait alors été annoncée pour faire converger BEA Workshop avec les autres outils d’Oracle. Et effectivement il existe aujourd’hui un Oracle Workshop for WebLogic 10g R3 basé sur Eclipse, etqui est progressivement migré dans la nouvelle offre Oracle Enterprise Pack for Eclipse (OEPE 11g).  :

Oracle l’avait clairement annoncé : “Oracle will seek to combine the capabilities of BEA’s Workshop development tool into Oracle’s Enterprise Eclipse Pack. Workshop users will be able to continue to use it in its familiar form in the Eclipse Pack. Oracle will continue development of its own JDeveloper tool and will add characteristics of BEA tools to JDeveloper, such as their design time modeling features. ”

Le socle historique de BEA Workshop avait été abandonné par BEA depuis le passage à la v9.2 (ou Studio 3.0), et les fonctionnalités marquantes telles AppXRay ont été portées sur Eclipse et maintenant diffusés par Oracle dans un modèle free et non open source.

Un autre socle logiciel a disparu sans causer de remous : celui de JBuilder, dont d’ailleurs les premières versions de JDeveloper étaient un fork commercial. Continuant les efforts initiés par Borland, la dernière mouture Embarcadero JBuilder 2008 R2 est basée sur Eclipse.

Le futur du socle JDeveloper est assuré non pas par les développements JEE / Spring, mais par tout ce qui existe à coté dans le portefeuille d’Oracle et qui n’est pas encore suffisamment stabilisé et standardisé par les communautés Eclipse ou JCP : SOA, WS-*, BPEL, Oracle Applications (OFM), BI, SCA… Il y aura donc bien maintenance conjointe par Oracle du socle JDeveloper et d’un jeu de plugins Eclipse (OEPE).

Ceci posé, comment peut se placer NetBeans ? Il suffit de le décomposer en ses diverses parties :

• un socle : NetBeans RCP Platform, qui est en concurrence et non compatible avec ceux de JDeveloper et d’Eclipse
• des plugins pour JEE 5, en concurrence avec ceux d’OEPE ou JDeveloper for JEE
• des plugins pour Glassfish, mais qui existent aussi pour Eclipse
• des plugins pour Java ME, C/C++, et PHP/Python/ruby/JS, Groovy/grails, qui sont en concurrence avec Eclipse Embedded & Mobile ainsi que les outils accessibles sur le portail Eclipse Language IDE.
• des plugins pour d’autres technos hors JEE : JavaFX, Profiler, Maven, Hudson, Ajax, services SaaS… qui existent peu ou prou également sur Eclipse, même pour JavaFX
• des plugins pour des assistants graphiques, comme UML, Visual Web, Visual Mobile ou Swing GUI Builder. Les deux premiers n’ont pas connu de succès auprès de la communauté NetBeans, et ils ont été retirés de la distribution officielle : “In order to focus our efforts on the latest and most popular developer technologies, the UML, SOA and Visual Web modules in NetBeans have been removed from the installer. The modules are available on the Beta Update Center or can be installed by via the Tools > Plugins menu in the IDE” précisent les notes de la release 6.7. Visual Web est en concurrence avec certains plugins open source pour Eclipse du projet Amateras. Swing Gui Builder est en concurrence avec Eclipse Visual Editor, mais VE n’est plus très vivace.

Il ne reste finalement comme différenciateurs que des outils pour les applications RIA ou Mobile : Swing, JavaFX Mobile, Java ME. C’est un domaine où Oracle était notablement absent.

En conclusion, mon pronostic est donc le suivant : maintien de la marque NetBeans pendant 1 ou 2 ans; abandon de la roadmap des plugins NetBeans en concurrence avec ceux de JDeveloper & OEPE; maintien des autres développements de plugins pour sortir une offre Oracle NetBeans qui concentre cette valeur et cette différence. Puis basculement progressif des fonctionnalités dans OEPE et/ou JDeveloper et arrêt des nouveaux développements sur le socle NetBeans, avec un support Oracle pendant quelques années pour les précédents clients utilisateurs de cette offre Oracle NetBeans.

Gavin et Red Hat étaient solidement arnachés grâce à SEAM 3 / Web Beans / JSR 299, laquelle est propulsée par JEE6 / JSR 316.

Le requin Rod et SpringSource, tournant autour du bateau de JEE 6, ne l’entendait pas de cette oreille. Et fin février le pied de Gavin a glissé du bateau JEE 6 (spécification générale et celle du profil web). Il vacille, et le statut de l’inclusion de la JSR 299 dans JEE 6 est devenu indécis.

Note – The expert group would like to solicit feedback from the community on whether to include Web Beans (JSR-299) 1.0 in the full Java EE Platform (see Section 6.30 of the Platform specification) and/or in the Web Profile. 

Note – The expert group hasn’t yet made a decision regarding the inclusion of the Web Beans 1.0 technology in the platform. The present section was added to solicit feedback from the community during public review.

Web Beans revendiquait depuis son origine (3 ans!) un héritage spirituel de Guice, mais Bob et Google étaient absents de la JSR 299. Google est bien présent en embuscade dans la JSR 316, malgré un dédain maintes fois affirmé pour JEE.

Et voila que depuis le 05 Mai, Rod et Bob proposent une nouvelle spécification “Annotations for Dependency Injection” ! Elle est très proche d’une petite sous-partie de la JSR 299, donc plus facile et rapide pour s’entendre sur ce standard. Et Bob pense qu’il est possible de monter un Groupe d’Experts et d’obtenir une validation finale de cette JSR en 5 mois (du jamais vu), juste à temps pour le round final de validation de JEE 6 en septembre. Gavin et Bob sont des potes (puisqu’on vous le dit) mais le débat fait rage depuis lors dans un fil de discussion technique des plus animés.

IBM, présent dans la JSR 299, mais aussi dans la 316, et Oracle/Sun, qui dirige la 316, vont devoir se positionner très vite.

Derrière ce débat d’apparence purement technique, c’est bien davantage le débat de la force des standards concernant Java pour l’entreprise, et l’enjeu de leur contrôle pour des acteurs historiques (Red Hat ou IBM avec un modèle JEE) ou de nouveaux entrants dans le monde de l’entreprise (Google avec un modèle JEGE à base de Guice 2 et Google App Engine, SpringSource avec Spring DM Server et leurs framework). Ce que l’on pourrait résumer en une phrase : assurer la portabilité des applications, c’est d’abord assurer leur passage vers le Cloud.

Désormais avec la sortie officielle de Java for Google App Engine, il faudra aussi compter dans le paysage le modèle d’applications JEGE (Java Entreprise Google Edition), qui utilise les “standards where relevant”.

Cette stack nous offre déjà dans le package :

• Servlet
• GWT
• Guice (et peut être bientôt JSR 299 qui a tant de mal à se faire accepter dans JEE6 ?) ; en tout cas pas de Spring à l’horizon
• JDO 2.3 ou JPA 1.0 avec le plugin DataNucleus
• pas d’EJB bien sur : EJB is legacy, même les Session 3.1
• REST (sans doute jax-rs)
• javax.cache
• javax.mail
• et un support du modèle batch
• sans oublier un plugin Eclipse avec un SDK local outillé
• ni un support de VPN entre les entrepôts de données de l’entreprise et les Google App(s) !
• ni les API pour les outils bureautiques et collaboratifs Google Apps
• et on peut parier sur un prochain support de certains langages sur la VM (Groovy, Scala…)

bien sur toujours avec un passage instantané entre le développement et la mise en prod !

Nos précédents essais avec GAE/Python nous ont montré que les problèmes de performances n’étaient pas toujours magiquement gommés, un apprentissage du bon découpage de l’application restait nécessaire. Il nous tarde de voir ce que ca donne avec des API bien mieux connues !

Les Quotas d’utilisation sont décrits ici. Vous trouverez aussi sur cette page les limitations imposées au runtime JRE.

L’estampille “certifié JEE” prend un coup dans l’aile. La valeur de Sun aussi du coup. Dommage que ses actionnaires n’aient pas accepté l’offre d’IBM à 7.4 b$, il se pourrait que la prochaine offre soit moins intéressante.

Salesforce a bien compris cette nécessité et offre depuis longtemps un tableau de bord très percutant sur leur niveau de disponibilité, consultable par tous, et qui fait envie à beaucoup de DSI.

Comme toute PaaS qui se respecte, Google App Engine se devait de présenter un service similaire. C’est chose faite désormais avec Google Status.

Ce qui est particulièrement intéressant c’est le focus mis sur la supervision de la latence des appels, avec un suivi pour les requêtes entre géants du cloud computing : de GAE vers AWS S3 par exemple.

On se rend alors compte que malgré les infrastructures massives de ces acteurs, la latence globale d’un appel (en comptant le délai du à la charge sur le service qui exécute l’API invoquée, donc pas uniquement de la latence réseau) :

• est la même si GAE invoque Google Search ou invoque AWS S3 (sur le même continent apparemment)
• présente un niveau bas vers 65ms mais jusqu’à 350ms en pic.

Dans un tel contexte, une application qui aurait à multiplier les appels vers plusieurs services distants (SaaS) pour une requête utilisateur présente un sérieux risque de problème de performance. J’ai toujours été sceptique sur la notion de mashups agrégeant dans une même vue plusieurs services distants (accédés sur WAN ou internet) et ces mesures viennent confirmer mes doutes. On retrouve ce problème pour les applications mixant les PaaS, ce qu’autorise la mise à disposition des API par ces éditeurs (une partie sur Force.com, une partie sur GAE, une partie sur Facebook, une partie sur S3…)

C’est une contrainte implacable à prendre en compte dès la conception d’une telle application, avec rechargement unitaire et gestion des erreurs de communication pour l’invocation de chaque service distant. La localisation du fournisseur de services sur le même continent que votre SI diminue cette contrainte, mais ne la supprime pas, loin s’en faut.

Un autre problème concerne plus spécifiquement GAE, et la limitation qu’il impose sur la durée d’exécution de chaque requête. Ce point est particulièrement sensible pour les accès à Datastore, leur API pour la persistance non relationnelle. Ces graphes montrent bien que la

durée totale d’exécution de votre requête peut varier en fonction de la charge instantanée sur les serveurs GAE. Une requête peut donc à un moment donné tomber en time-out alors que “d’habitude elle passe sans problème”. Ce n’est pas un bug mais une conséquence de l’utilisation d’infrastructures mutualisées. Votre application GAE, ou qui consomme un service exposé sur GAE, devra nécessairement prendre en compte cette cause d’échec et la gérer de manière adéquate en fonction de la criticité de votre application.

Bon, en vrac, j’ai retenu que :

Orange se met sérieusement à Flex dans le cadre de son programme Telco 2.0, avec comme réalisation visible Pikeo.

MAAF, après une étude comparative approfondie de toutes les technos RIA du marché, a fait le choix de Flex pour son framework 3M@ (à noter que RCFaces de Vedana, petite société française était en coude à coude, mais éliminé pour cause de pérennité). Ils ont éliminé GWT car – je cite – « son modèle de programmation des IHM ne respecte pas les standards émergents« . On se demande un peu ce qu’est cette notion de standard émergent qui permet d’éliminer GWT et de retenir Flex.

SQLI, partenaire stratégique d’Adobe, a accompagné ETAM pour son projet de poste client directement connecté à SAP. A noter que l’application était déployée sur des TPV (Terminaux Point de Vente) : grosso modo c’est un Windows XP, 800×600, 128 Mo de RAM, avec IE seul (et son Flash Player bien sur !), j’ai oublié la fréquence du processeur mais cela montait pas bien haut. On constate donc qu’une RIA Flex peut très bien tourner sur une brouette Le retour de SQLI est que Flex Builder a permis une courbe d’apprentissage très courte des développeurs de connaissant pas Flex mais Java (donc Eclipse) et que la productivité de l’IDE et du language a permis de tenir le planning. BlazeDS sur GlassFish a été utilisé pour le Remoting (pouvoir appeler de façon transparente les POJOs du backend depuis l’application cliente Flex).

CAP Gemini a accompagné la SNCF (Fret) dans le cadre de son programme PRU (Programme de Remise Unifiée). L’application était très « datagrid-centric » avec des tableaux allant jusqu’à 60 colonnes, et une gestion très particulière de la navigation dans les cellules via la touche Tab. Cela aurait été une belle partie de plaisir de faire ça via un framework Ajax ! Les exigences de la SNCF était claires : Simplicité, Performances (malgré un tuyau réseau faible -> donc limiter le transit au maximum) et Maintenabilité. Les performances ont tenu, notamment grâce à AMF et la maintenabilité assurée par le langage ActionScript, puisque unique et objet.  De plus, CAP estime avoir aussi gagné en productivité :  80% du code développé dès la semaine 18, contre semaine 25 en HTML/JS). L’architecte CAP définit Flex comme – je cite –  » que du bonheur ! ». Le client est aussi satisfait, et a déjà choisi Flex pour son prochain projet.

A noter aussi que les 2 projets ont apprécié la formation rapide des utilisateurs, due à la convivialité et la simplicité des RIA développées.

En conclusion, retours très intéressants donc, et je regrette d’avoir du partir avant la présentation des Tontons à 19H00 au sujet des nouveautés annoncés à Milan (MAX 2008). Mais nul doute que quelqu’un va vite se charger de publier un petit billet sur le sujet.

Je ferai une mise à jour de ce billet pour une autre approche RDA quand elle sera disponible : MS Office Web Application.

Il ne s’agit pas vraiment ici d’argumenter sur la valeur de l’approche RDA vs l’approche traditionnelle des applications bureautiques, puisque même Microsoft s’est rallié à une approche RDA. Mon envie est plutôt de partager une analyse sur les offres d’applications bureautiques vues sous l’angle de l’Entreprise 2.0

  Mais commençons tout d’abord un petit tour du nouveau Lotus Symphony

L’approche RDA de Symphony est bien celle intégrée jusqu’à présent à la stratégie de l’offre portail d’IBM avec l’offre Lotus Expeditor.

L’offre Symphony est une tentative d’IBM de profiter de l’avancée d’OpenOffice dans les entreprises. L’offre de Sun n’est jamais citée dans les présentations d’IBM, à la différence de MS Office avec qui le comparatif est clairement établi.

Symphony fonctionne sous :

• Supported Windows platforms: Windows XP, Windows Vista
• Supported Linux platforms: Suse Linux Enterprise Desktop 10, Redhat Enterprise Linux 5, Ubuntu 8.0.4 LTS
• Supported Mac OS platforms: MacOS X 10.5 (Intel)

 Son accessibilité pour sa mise en œuvre

Ce sont des critères primordiaux pour une cible de diffusion très large.

Symphony est donc :

• Gratuit mais pas open source
• Disponible dans 28 langues
• Nécessite de s’enregistrer sur le site IBM pour le téléchargement ;
• 200 Mo à télécharger pour l’installeur ;
• Processus d’installation très similaire à OOo ;
• L’installation ne demande pas de redémarrage du PC ;
• Emphase mise sur l’ergonomie façon Chrome
• Support officiel IBM disponible pour les entreprises;
• Empreinte disque une fois installé :

A comparer avec OOo 3.0 :

Avec MS Office 2003 : 275Mo, 974 fichiers (sans les fichiers Media et les bibliothèques partagées de windows)

Et avec Chrome : 55 Mo, 166 fichiers

 Soulevons le capot de Symphony

On y découvre la plateforme eRCP

Symphony package de nombreux OSS (cf le document de licence) :

Apache Ant v.1.6.5 Apache Axis v.1.4 Apache Harmony: - * auth (Subversion 653525 20080522) * beans (Subversion 653525 20080522) * concurrent (Subversion 653525 20080522) * jndi (Subversion 653525 20080522) * logging (Subversion 653525 20080522) * luni (Subversion 571234 20070830) * nio (java) (Subversion 653525 20080522) * nio (natives) (Subversion 571234 20070830) * pack200 (Subversion 658191 20080520) * portlib (Subversion 571234 20070830) * prefs (Subversion 653525 20080522) * regex (Subversion 653525 20080522) * security (Subversion 653525 20080522) * sql (Subversion 653525 20080522) Apache Jakarta Commons BeanUtils v.1.6 Apache Jakarta Commons Codec v.1.3 Apache Jakarta Commons Collections v.2.1.1(subset) Apache Jakarta Commons Collections v.3.1 Apache Jakarta Commons Digester v.1.5 Apache Jakarta Commons Discovery v.0.2 Apache Jakarta Commons EL v.1.0 Apache Jakarta Commons HttpClient v.3.0 Apache Jakarta Commons Lang v.2.2 Apache Jakarta Commons Logging v.1.0.4 Apache Jakarta JSP Standard Tag Library v.1.1 Apache Jakarta Tomcat Jasper2 v.1.0 Apache Lucene v.1.9.1 (subset) Apache Tomcat v.5.5.17 Apache Xalan-Java v.2.7 Apache Xerces v.4.4 BCEL v.5.0 Bitstream Vera Fonts v.1.10 Boost v.1.27 Bzip2 v.1.0.3 (subset)

Cairo Binding Cairo Library v.1.0.2 Eclipse v.3.4.0 Eclipse EMF v.2.4.0 Eclipse Equinox (OSGi Services) v.3.4.0 Eclipse eRCP v.1.2 SWT Mobile Extensions Eclipse XSD v.2.4.0 Expat v.1.2 Expat v.1.95.7 fdlibm v.1.5 Firefox v.2.0.0.3 (subset) Freetype 2.1.4 ICU4C v.3.4.1 ICU4J v.3.8.1 Independent JPEG Group’s LIBJPEG Release 6B Java API for XML-based RPC (JAX-RPC) JavaCup v.10k java.util.concurrent v.JSR166_PFD JHotdraw JPEG 6b Libpng v.1.2.7 log4cxx-0.9.7 MATH DTD v.4.01 MD5 Mozilla Binding msvcr71.dll Nameprep v.1.1 OpenOffice.org v.1.1.0 OSGi Materials 4.1.0 Pixman v.0.1.6 Punycode v.2.0.0 Putty v.0.58 RegExp v.1.2 Root Certificates SOAP with Attachments API for Java (SAAJ) SQLite v.3.3.5 STLPort v.5.0.2 Unicode Data Files W3C DOM Level 3 Core specification WSDL4J v.1.5.1 XHTML DTDs v.1.1 XML4C v.5.6.2 XML4J v.4.3 XML-APIS v.1.3 XSLT4C v.1.7 XULRunner v.1.8.1.3 Zlib v.1.1.4 Zlib v.1.2.3

On remarque un fork de OOo 1.1 dans C:\Program Files\IBM\Lotus\Symphony\framework\shared\eclipse\plugins\com.ibm.productivity.tools.base.app.win32_3.5.0.20081031-1700.

Symphony sait lire/écrire les documents MS Office 2003, OOo 1.1, mais pas ceux de MS Office 2007 (docx). Le support de docx dans OOo 3 est il est vrai assez limité.

Il déclare lire les formats ODF, mais un essai de lecture d’un fichier .odt moyennement complexe généré par OOo 3 s’est soldé par un freeze général de Symphony.

Grace aux logs Eclipse on trouve que l’erreur est lancée par un module de Expeditor (le nom du produit commercial dont est directement issu Symphony) : La commande (« org.example.command.markKeywords ») n’est pas définie" severity="50"

Formats de lecture pour Symphony :

Le navigateur intégré de Symphony

C’est le bonus de cette offre.

Firefox 2 est également mentionné dans la liste des composants mais c’est bien votre IE (dans le cas de Windows) qui est activé quand on utilise la fonction de browser intégré, mais d’une façon assez particulière.

Le module IBM appelé IEOOP.exe est activé dans C:\Program Files\IBM\Lotus\Symphony\framework\rcp\eclipse\plugins\com.ibm.rcp.swt.browser.dom.ie_6.2.0.200810171336\os\win32\x86

IEOOP n’est pas repéré par le gestionnaire de mémoire de Chrome :

Il est chargé de customiser les menus de IE et de réaliser un partage des informations (cookies notamment) entre les multiples threads pilotant les IE-fils qui sont lancées, avec le support de tous vos plugins IE, et notamment Java, flash et acrobat.

Le clic droit sur les liens « ouvrir dans une autre fenêtre » est bien géré et ouvre un nouvel onglet dans Symphony

On ne voit pas du tout d’instance IEXPLORE.exe de 48Mo (minimum pour IE6 sp2 installé sur mon poste WinXP) pour chaque « onglet » simultané lancé via la fonction de browser intégré.

Les 168Mo observés pour IEOOP correspondent à 8 onglets simultanés ouverts sur des services de google avec beaucoup de JS.

Le processus IEOOP monte ainsi à 41 threads ce qui est très significatif sur windows (pour information j’avais 40 onglets ouverts dans l’instance Firefox et 8 dans Chrome). IE 6 crée 23 threads avec une fenêtre.

Le support du JS dans le browser intégré (via la customisation d’IE imposée par IEOOP) semble identique à celui offert par l’IE lancé normalement (même résultat de 12 ou 13/100 au test ACID3).

On peut sélectionner un autre navigateur dans le menu Préférences mais il s’ouvre alors comme une application hors du contexte Symphony.

Autres composants techniques originaux

La stack technique de Symphony comprend outre Tomcat et Axis une bonne partie du container SCA Apache Harmony est situé dans C:\Program Files\IBM\Lotus\Symphony\framework\rcp\eclipse\plugins\com.ibm.rcp.dee.win32.x86_6.5.0.200810171336\jre\lib\jclDEE\classes.zip

Dans cette même archive on trouve un encodeur/décodeur ASN1. Protocole certes très compact et efficace mais je ne pensais pas le trouver dans un produit bureautique.

Ces composants servent au service de mise à jour de parc dans le cadre de déploiement en entreprise :

Symphony tourne sur la JVM compacte j9 d’IBM :

Mise à jour, plugins et extensions

La logique de la mise à jour de Symphony est traditionnelle, et laissée au gré de l’utilisateur. Chrome quant à lui se met à jour automatiquement (vérification à chaque démarrage) et surtout sans intervention de l’utilisateur. Pour l’instant si on peut ajouter des extensions NSAPI, les plugins sont interdits.

C’est une procédure en 15 clics (celle d’Eclipse évidemment), qui convient à un développeur mais pas à un utilisateur non informaticien.

Les plugins tiers sont installés dans le profil utilisateur :

Arrrgg !

Mais il s’agit en fait de redémarrer simplement Symphony, et pas le PC.

Certains plugins sont maintenant accessibles dans la barre latérale et peuvent s’ouvrir dans des fenêtres RCP séparées :

Le menu principal au dessus des onglets change en fonction de l’application utilisée, à la OpenDoc d’Apple.

Comparaison de l’empreinte mémoire des solutions bureautique (ouverture simultanée d’1 document dans word ou équivalent, excel, ppt)  :

MS Office 2003 (3 documents ouverts ici dans word) :

OOo 3.0

Symphony 1.2 avec 3 onglets bureautique

Chrome 0.3 avec 3 onglets Google Apps :

Conclusion

Je la rédige, patience !

  Scoop : le Google Chrome nouveau arrive ! Et il a un goût bien connu…

A lire ici.

Je vois surtout ici une tendance nette des réseaux sociaux à se placer dans le courant des Plates-formes as a service pour gagner en popularité et en valeur ajoutée, en plus de créer un petit écosystème. On y reviendra bientôt.

Un peu d’historique sur les annonces de PaaS :

• Force.com le premier en 03/2007
• Puis Facebook f8 en 05/2007
• MySpace en 10/2007
• Google App Engine en 05/2008

Et aujourd’hui enfin LinkedIn se positionne. Deux éditeurs sur 4 sont historiquement connus par les offres de réseaux sociaux. Force.com n’a pas oublié d’introduire un service AppExchange dans sa panoplie, ni GAE un répertoire des applications. Le point commun est d’ajouter une fonction de canal de distribution à la solution de l’éditeur. On comprend tout de suite la puissance d’un réseau social comme canal pour diffuser une application par le marketing viral. Dans cette logique, le canal de distribution devient la plate-forme. Google n’a pas encore jugé bon d’associer Orkut à GAE, mais je prends les paris que ca ne saurait tarder.

Mais l’ouverture actuelle de LinkedIn vers une PaaS est encore très très réduite, puisque voilà ce que nous dit la FAQ :

Submission of Developer Application

How can I get LinkedIn to use an Application I’ve built?

If you have developed an application that would benefit LinkedIn Network professionals, submit an email to our LinkedIn developers for consideration by taking the following steps:

1. Click on ‘Widgets’ found in the navigation footer at the bottom of the home page.
2. Click on ‘Send us a message’.
3. Complete the email by describing the application you’d like to apply, what you need from us, and what your application will do with the data.

LinkedIn a bien compris le sens de l’histoire, et je serai étonné qu’ils se contentent longtemps de permettre de développer et déployer des applications par mail interposé. Pendant ce temps bien sur, la concurrence améliore ses PaaS.

Avec peu de standard d’interopérabilité des applications (hormi OpenSocial, mais encore peu déployé chez les réseaux sociaux leaders), on s’attend à du lock-in en perspective pour les développeurs oeuvrant sur ces plates-formes. C’est le lot de toutes les plates-formes naissantes. Aux éditeurs tiers de choisir le bon cheval, sachant que dans l’univers des éditeurs sur le web le premier parti garde longtemps une longueur d’avance.

Le produit, une version allégée de Microsoft Office desktop, sera à base d’HTML/Ajax et/ou (ce n’est pas très clair) de Silverlight.

Attention à ne pas le confondre avec Office Live workspace qui permet de partager des documents office classiques, ou avec office online un site d’aide à l’utilisation d’Office Desktop.

Bref grosse annonce, mais beaucoup de questions. Comment Microsoft va t-il positionner les versions online et desktop de sa suite bureautique ? Quel modèle tarifaire ? Quelles interactions entre les deux ? Comment tout celà s’inscrit-il dans la logique Software + Service ?

Et vous, quel est votre besoin prioritaire lorsque vous travaillez sur un document ? L’édition du document lui-même ou le travail collaboratif autour du document ? Vous utilisez déjà un traitement de texte en ligne, vous allez le faire, ou jamais de la vie ?