Discussion :

[randriano]

Bonjour,

Je me demande seulement comment gère-t-on le développement des logiciels qui existent pour plusieurs plate-formes (écrits avec un langage non portable comme Java)
Ex: Mozilla Firefox

Sur quelle plate-forme a travaillé d'abord l'équipe de développement?

[hegros]

Bonjour,

Je me demande seulement comment gère-t-on le développement des logiciels qui existent pour plusieurs plate-formes (écrits avec un langage non portable comme Java)
Ex: Mozilla Firefox

Sur quelle plate-forme a travaillé d'abord l'équipe de développement?

Justement java est portable, ceci explique cela.

La plate-forme cela peut-être n'importe quoi pourvu qu'il y existe un compilateur (java par exemple) ou un cross-compilateur dans le cas de langage compilé(c++ par exemple)

[wiztricks]

Un développement dépend de fonctionnalités qu'à ou n'a pas la plateforme.

Si on veut réduire les soucis de "portage", on utilisera un langage disponible partout: Java, C, C++ ou encore Python, Ruby, etc... sont de bons candidats.

Ensuite vous allez définir les fonctionnalités "au sens large" que devra avoir la plateforme pour supporter votre logiciel et arbitrer à partir de quels composants vous allez construire ces fonctionnalités.

Ex: Si vous avez besoin de persistence, vous pourrez utiliser des fichiers plats ou une base de donnée. Et dans ce cas, choisir un SGDB qui sera disponible sur l'ensemble des "OS" que vous ciblez.

Pour revenir à Mozilla/Firefox, les spécificités de l'OS sont masquées par la Netscape Portable Runtime. C'est une bibliothèque qui fourni des API indépendantes de l'OS.
=> Mozilla est développé "au-dessus" de cette couche abstraite.
Si on souhaite porter "Mozilla" sur une plate-forme non encore supportée, on porte d'abord la NSPR puis on compile Mozilla.

-W

[randriano]

Pour revenir à Mozilla/Firefox, les spécificités de l'OS sont masquées par la Netscape Portable Runtime. C'est une bibliothèque qui fourni des API indépendantes de l'OS.
=> Mozilla est développé "au-dessus" de cette couche abstraite.

Là c'est clair !!

Donc l'équipe doit donc développer ce genre de couche logicielle avant tout?

[souviron34]

ben oui..

En fait, le fond du problème est : minimiser le travail pour passer d'un OS à l'autre..

Donc en fait, il faut maximiser le code portable (quel qu'il soit : langage C, C++, ...).

Si on a des GUI, c'est pareil.. Maximiser le code portable (méthodes et traitements).

Ensuite on peut si on le souhaite utiliser un outil graphique portable (style Java). Mais ce n'est pas obligatoire.... Tout dépend des différences entre OS sur ce qu'on veut, des standards existants, des contraintes, etc etc...

Pour mémoire, les navigateurs style Netscape/I.E. sont conçus autour du même code développé par le CERN/NCSA, en C.. Autour, il y avait le widget d'interprétation/présentation HTML, qui était X, et qui a été porté à Windows avec la Windows API.

En gros, la structure d'un tel projet serait :

• bibliothèques indépendantes
• bibliothèques dépendantes
• sources dépendants
• sources indépendants
• Makefile

Pour répondre à ta question, la plupart ont été développés au départ sur des platefrmes unixoides (Unix ou Linux)

[wiztricks]

Cette approche n'est pas seulement nécessaire au développement d'applications portable.

Le design de haut niveau définit une abstraction souvent éloignée des API bruptes offertes par l'OS ou les autres composants qui seront utilisés.
C'est une démarche descendante certes mais on s'arrête à la définition de primitives de haut niveau qui seront organisées/groupées par domaines/composants/packages.

Dans le design détaillé, on va spécifier la réalisation de ces primitives de haut niveau à partir des API "bruptes" s'il n'y a pas de contrainte de portabilité ou en encapsulant encore ces "API bruptes" via un "adaptateur" ou un wrapper.

Sans parler de portabilité, si demain il est judicieux de changer ou faire évoluer la technologie, seul l'adaptateur est à ré-écrire et/ou à tester de façon "forte".

L'adaptateur permet de visibiliser les dépendances que l'application a avec le composant qu'elle utilise. De plus, l'API du composant est parfois bien trop riche par rapport aux besoins d'une application: l'adaptateur permet de simplifier et éventuellement optimiser l'utilisation de cette API.

-W