Une autre solution, élégante mais parfois plus lourde à mettre en place, est celle utilisée par gimp: un plugin est un programme séparé, le coeur et le plugin discutant par des pipes.
Les avantages sont les suivants:
- les problèmes de stabilité du plugin n'affectent pas le coeur, alors qu'un accès mémoire foireux dans un .so entraine le crash de tout le programme
- les pb de licences sont clairs: chacun choisit la licence qui lui plait
Les inconvénients:
- les zones mémoires sont disctinctes, et à moins d'utiliser de la mémoire partagée, le partage des données peux vite être lourd
- nécessite la définition d'un protocole de type client/serveur avec tous ses inconvénients (asynchronismes, etc.)
[^] # Re: Méthode artisanale
Posté par left . En réponse au message Architectures à plugins: comment les réaliser en pratique?. Évalué à 3.
Les avantages sont les suivants:
- les problèmes de stabilité du plugin n'affectent pas le coeur, alors qu'un accès mémoire foireux dans un .so entraine le crash de tout le programme
- les pb de licences sont clairs: chacun choisit la licence qui lui plait
Les inconvénients:
- les zones mémoires sont disctinctes, et à moins d'utiliser de la mémoire partagée, le partage des données peux vite être lourd
- nécessite la définition d'un protocole de type client/serveur avec tous ses inconvénients (asynchronismes, etc.)