Meilleure intégration des applications dans les OS

[tulipebleu]

Bonjour,

Je trouve que les applications ne sont pas biens intégrés aux systèmes d'exploitation.

L'idée, c'est que l'application déclare ce qu'il a besoin, et que l'OS ne donne à l'application que ce qui lui est nécessaire, et enfin que l'utilisateur puisse consulter ce que l'application a déclarer.

Pour améliorer cela, je pense qu'il faudrait que quand une application s'installe, avant de faire quoi que se soit, elle se déclare à l'OS, et ce dernier lui donne un nom unique ainsi qu'un répertoire dans lequel l'application pourra s'installer. Une fois cela fait, l'installeur décompresse ces fichiers dans le répertoire de l'installation et fini l'installation.

Le nom de l'application est proposé par l'installeur, et l'OS gère l'unicité comme il veut. Par exemple, il peut ajouter un chiffre au nom (par exemple filezilla156), ou il peut demander à l'utilisateur de mettre un nom unique (par exemple filezilla64bits).

Quand l'application se déclare, elle défini un certains nombre de propriété. Ces propriétés peuvent être modifiées après coup par l'application. Parmi les propriétés possibles, il y a par exemple les dépendances de l'application, les variables d’environnement propre à l'application, les ports d'écoute utilisé, les répertoires ou les fichiers de configuration. Il peut y en avoir autant que nécessaire. Certaines de ces propriétés sont standardisées. Le format de la déclaration est en XML, en utf8 avec un bom obligatoire.


Voici un exemple de déclaration de l'application SuperFtp (application fictive qui fait serveur FTP) :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<?xml version="1.0" encoding="UTF-8"?>
<application>
	<nom_officiel>SuperFtp</nom_officiel>
	<developpeur>moi</developpeur>
	<organisation>mon organisation</organisation>
	<version>1.23</version>
	<url_update>http://monorganisation/SuperFtp/update</url_update>
	<port_serveur>21,22,23,1000-2000</port_serveur>
	<config>
		<fichier>conf/config.xml</fichier>
	</config>
	<temp>
		<repertoire>temp</repertoire>
	</temp>
	<env>
		<path>bin</path>
	</env>
	<dependances>
		<application>
			<nom_officiel>Autre Application</nom_officiel>
			<organisation>mon organisation</organisation>
			<version>2.x</version>
		</application>
		<application>
			<nom_officiel>Autre Application2</nom_officiel>
			<organisation>autre organisation</organisation>
		</application>
		<module>
			<nom_officiel>os.net.serveur</nom_officiel>
		</module>
		<module>
			<nom_officiel>os.fs</nom_officiel>
		</module>
		<module>
			<nom_officiel>os.gui</nom_officiel>
		</module>
	</dependances>
</application>

Dans cet exemple, l'application s'appel SuperFtp. Ce nom officiel est en fait le nom courant de l'application. Il peut être différent du nom unique de l'application au niveau de l'OS.
La balise url_update indique où récupérer le fichier de description de la dernière mise à jour. Ce fichier indique le numéro de la dernière version, et aussi ou récupérer l'installeur pour la mise à jour. C'est l'OS qui va s'occuper de faire la mise à jour, en vérifiant s'il y a une mise à jour, et en la faisant a un moment ou l'application ne fonctionne pas.
L'application peut utiliser les ports 21,22, ou 23 ou les ports entre 1000 et 2000. Cela ne veut pas dire que quand l'application se lance, tous ces ports sont utilisés, mais plutôt que si elle en utilise, elle n'utilisera que ces ports. L'OS empêchera l'application d'utiliser un autre port que ces ports déclarés.
La balise config indique le fichier de configuration. Il peut y avoir plusieurs fichiers, et il peut y avoir aussi des répertoires. Cela peut servir pour indiquer a un programme de sauvegarde le répertoire à sauvegarder. Le chemin est relatif au répertoire de l'application.
La balise env indique les variables d'environnement spécifique à l'application. la aussi, les chemins sont relatif à l'application, c-a-d que la variable path indique qu'il faut ajouter /repertoire_de_l_application/bin à la variable d'environnement path.
Les dépendances indiquent ce que l'application peut faire et ce qu'elle ne peut pas faire. Ici, l'application dépend d'une autre application qui se nomme "Autre Application", et qui doit être en version 2.0 ou plus. Si cette autre application n'existe pas, il n'est pas possible d'installer SuperFtp. SuperFtp dépend aussi de plusieurs modules du système d'exploitation. Le système d'exploitation a toujours le nom os. Dans cet exemple, SuperFtp dépend du module système os.net.serveur. Cela signifie qu'il peut utiliser les fonctions de l'Os pour être un serveur. Par contre, comme il ne dépend pas du module système os.net.client, il ne peut pas utiliser les fonctions réseaux clients, autrement dit, il ne peut pas télécharger un fichier sur le réseau. Il n'a pas non plus de dépendance envers les fonctions de bas niveau réseau. Il a une dépendance au niveau du système de fichier, et aussi pour afficher des fenêtres. Pour le système de fichier, il ne peut par défaut lire et écriture que dans son répertoire d'application. S'il a besoin de lire un autre répertoire il fallait le déclarer. Les dépendances sont gérées par l'OS. Si par exemple, l'application veut appeler une fonction qu'il n'a pas déclarée, l'OS arrête l'application. Cela permet de bloquer les virus qui s'injectent dans les applications serveurs.

Il existe une commande batch pour consulter le paramétrage d'une application. La commande "app application" donne la liste des applications, et "app config SuperFtp" donne la configuration de l'application qui a pour nom SuperFtp.

Avec ce mécanisme, il est possible :

• d'avoir la liste des applications
• de mettre à jour toutes les applications, et pas seulement ceux de l'OS
• de sauvegarder la configuration des applications pour pouvoir les transférer sur un autre PC
• de mettre un quota disque par application
• de consulter la taille de chaque application
• de demander à l'OS de déplacer une application d'une partition à une autre
• de comprendre a quelle application appartient tel processus mémoire
• pour une application de connaitre son répertoire. Fini les variables d'environnements qui ne servent qu'à cela. L'application peut bien sur aussi connaitre son nom unique en le demandant à l'OS
• de mieux isoler les applications, et donc de mettre les battons dans les roues des virus et chevaux de trois. Cela ne règlera pas tout, mais c'est un progrès
• de définir des alias. Par exemple, il y a une application App1 qui dépend de Java. A la première installation, c'était l'application Java5_0_19 qui été installé. il est tout a fait possible de créer un alias Java et de le faire pointer vers Java5_0_19, et de faire pointer App1 vers Java au lieux de Java5_0_19. Ensuite, si Java7 est installé, il suffit de faire pointer l'alias Java vers Java7 pour que App1 utilise Java7.
• d'utiliser un mécanisme de module pour les applications non système. Par exemple, il peut y avoir OpenOffice.writer, openOffice.calc, MsOffice.Word, etc...
• de connaître le répertoire temporaire, et de le supprimer quand l’application ne fonctionne pas, ce qui permet de gagner de la place.
• de savoir si une application est encore utilisé par une autre application

Il est possible d'installer des applications qui utilisent ce mécanisme, avec d'autres applications qui ne l'utilisent pas.

Il est possible que certaines de mes idées soient passées à la trappe, car j'avais eu cette idée en 2008.

[gangsoleil]

Bonjour,

Ca semble pas mal, et d'ailleurs on peut voir une logique un peu similaire dans les paquets FreeBSD (notamment le repertoire unique pour chaque application).

Les problemes que je vois :
Gestion de conflit
Comment faire lorsque, par exemple, une nouvelle application souhaite utiliser un port deja "utilisable" par une autre ? Si on dit que l'OS peut le changer, cela suppose que les applications sont bien developpees, c'est a dire que le numero de port est configurable, mais aussi qu'il existe un moyen de prevenir tous les clients que, sur cette machine, l'appli A n'utilise pas 1234 mais 2345. Difficile.

Non-applicable aux librairies partagees (qui posent deja probleme).
Deux solutions : chacun vient avec son lot de librairies partagees, c'est a dire avec ses versions (parfois obsolete), et pose tout dans son repertoire. Cela suppose donc qu'en cas de bug dans une lib, il faut que l'OS soit au courant de toutes les versions de toutes les libs qui sont deployees, et qu'il y ait un moyen de dire si oui ou non le programme autorise les update.
Sinon, on met toutes les librairies partagees dans un meme repertoire, et on se retrouve avec les problemes actuels de librairies qui cassent la backward compatibilite : la mise a jour de la lib va empecher certains programmes de fonctionner.