Cet article fait suite à mes commentaires sur un article de Gilles Blanc. J' y réagis à une affirmation que la tendance observée d'utiliser un navigateur Web comme interface graphique d'un produit embarqué est parfaitement appropriée, même quand le produit n'a nullement pour objectif ni nécessité de se connecter sur le Web, ou encore de fournir une interface déportée (paramétrage à distance d'une imprimante par navigateur Web, par exemple).
Je précise que Gilles Blanc est ingénieur chez Linagora, société de taille respectable spécialisée dans l'open source. Je suis pour ma part ingénieur spécialisé dans l'embarqué "haut de gamme" (c'est à dire capable de faire tourner un Linux; par opposition au "petit embarqué" basé sur un micro-contrôleur 8 bits où un OS serait impensable et de toutes façons, superflu).
Il se trouve que l'entreprise pour laquelle je travaille a adopté cette solution, après avoir évalué superficiellement une solution classique du style nano-X (GUI basé sur "frame buffer"). J'ai eu dès le départ des doutes sur la pertinence de celle-ci. J'en ai fait part quand on m' a demandé mon avis sur la question, puis on ne m' a plus demandé mon avis. Malheureusement, quasiment toutes mes craintes ce sont avérées justes, et après 6 mois/homme de travail (par mes collègues) le produit n'est que "presque" fini. Le pire est que certaines de mes doutes portaient également sur l'exploitation du produit fini.
Pourquoi ai-je vu dès le départ l'utilisation d'un navigateur Web comme interface graphique d'un mauvais oeil? Il suffit de considérer les choses d'un point de vue purement technique: pour faire tourner une interface graphique "Web" il faut:
- Un navigateur Web. On sait que les "browsers" ne font pas partie des applications les plus légères et les plus simples. Ce qui se traduit par consommation élevée de ressources et une source de bugs potentielle.
- Un serveur X11 ou équivalent. Encore des ressources consommées, encore une source potentielle de problèmes. Soit dit en passant, il existe au moins un portage de Webkit qui permet de se passer de X11, mais le portage de celui-ci sur notre premier prototype a été un échec pur et simple malgré l'aide (rémunérée) des auteurs.
- Un serveur HTTP, car le navigateur, pour énorme qu'il soit ne sait rien faire tout seul. Il existe des serveurs HTTP vraiment très compacts, mais reste qu'on puise encore dans les ressources et qu'on installe encore une source de problèmes.
Par comparaison, pour une interface graphique construite avec les moyens classiques on a besoin:
- D'une librairie GUI capable de fonctionner sur frame buffer.
J'insiste sur les "sources de problème potentielles", car c'est une dimension importante pour un produit commercial. Si l'un des composants de l'ensemble logiciel se comporte mal (fuite mémoire, crash - et soit dit en passant, si vous réutilisés du logiciel développé à l'origine sur PC il faut être conscient que sur PC, une fuite mémoire, un "freeze" ou un plantage ne semble pas aussi préoccupant que dans l'embarqué), vous avez le choix entre corriger vous même le logiciel, ou attendre que les auteurs ou la communauté le corrige. Dans les faits, le second terme de l'alternative n'est pas toujours envisageable. Quant au premier: déboguer un problème se produisant dans un empilement de quelques centaines de milliers de lignes de source est un problème redoutable.
La comparaison parle d'elle-même, mais n'est pas tout à fait juste car quand même un navigateur Web ne consomme pas des méga-octets de RAM et flash sans raison. Cette raison est que tout ce qui apparaît dans un navigateur Web est "scripté": Javascript, CSS, HTML.
Cela offre il est vrai certaines facilités et une certaine souplesse. Mais observons que d'une manière générale dans l'embarqué, les logiciels sont beaucoup plus figés que dans le monde du PC, car les produits sont conçus pour répondre à un cahier des charges assez précis. Si toutefois on veut un peu de cette souplesse avec une solution classique, il existe une demi-douzaine de langages de script embarqués (Lua vient immédiatement à l'esprit).
Un argument qui revient souvent lorsque l'on parle de performances et d'efficacité des technologies est que "les cycles CPU comptent moins que les cycles développeur". Là encore, cet argument est beaucoup moins défendable dans le domaine de l'embarqué que sur PC. La raison est que les produits embarqués forment un ensemble matériel et logiciel commercialisés sur un marché concurrentiel. Comme je l'ai indiqué précédemment, la partie logicielle est relativement figée, donc le coût des développements l'est également, et est divisé par le nombre d'unités vendues. A contrario, le prix du matériel pèse sur chaque unité vendue. Donc, d'un point de vue purement financier, on a dans ce contexte beaucoup plus intérêt à réduire le coût matériel que celui des développements logiciels. Concrètement, j'estime (sur la base du fait que le processeur coûte de fois plus cher) que le prix de revient du matériel nécessaire pour faire tourner un navigateur est 50% plus élevé que celle nécessaire pour faire tourner la solution classique.
Le prix de revient matériel plus élevé est-il compensé par un coût de développement moins élevé? Pour être juste, cela dépend beaucoup du prix du matériel et du nombre d'unités produites.
Mais il y a plus problématique pour fonder une estimation: la productivité d'un développeur est difficilement mesurable. En particulier, rien ne permet de dire a priori s'il est plus rentable de développer une interface en C/C++ plutôt qu'en Ajax/HTML/CSS. Cela dépend grandement de l'expérience du développeur dans le domaine.
Quitte à choisir entre les deux, et au risque de donner l'impression de défendre mon territoire, mieux vaut choisir un développeur embarqué pour de l'embarqué; c'est une question de bon sens (et donc, votre homme connaitra de toutes façons C/C++ et saura traiter avec Qt ou autre). Le titre de développeur embarqué n'est tout même pas une médaille en chocolat. On doit faire preuve de rigueur et de parcimonie, car toutes les ressources (cycles CPU, flash, RAM) sont le plus souvent limitées et non extensibles; les mauvais fonctionnements, les crashs sont des plaisanteries assez peu goûtées (surtout si l'utilisateur est un client qui a déboursé une certaine somme; et a fortiori quand le système à une mission un tant soit peu critique); les moyens de déboguage et d'analyse post mortem sont souvent limitées. Du point de vue d'un développeur embarqué, les problèmes d'incontinence avec la mémoire, d'exceptions non interceptées, d'obésité injustifiables, de latences injustifiées, et cætera, de pas mal d'applications (y compris commerciales!) sont consternants.
Le choix d'utiliser un navigateur Web comme interface graphique plutôt que les technologies habituelles ne peut donc pas se faire sans discernement. Si on ne cède pas trop facilement au phénomène de mode ou à la séduction (j'ai envie de dire "coolitude"), et qu'on analyse d'une manière rationnelle les faits, force est de constater que cette solution n'est pas sans inconvénients notables. Il s'agit donc d'une solution adaptée à des applications précises plutôt que d'une solution généralisable à toute application.
Articles
