Forum Programmation.autre Architectures à plugins: comment les réaliser en pratique?

Posté par  (site web personnel) .
Étiquettes : aucune
0
19
juil.
2007
On connaît l'intérêt des plugins pour les logiciels libres, notamment pour éviter les forks et permettre des spécialisations sans affecter le coeur du logiciel.

Ma question est assez concrète: y a-t-il des pratiques reconnues, en matière de programmation, pour mettre en place un système de plugins (interfaces, design patterns, etc) ?

Avez-vous des expériences sur des projets concrets ?

  • # Méthode artisanale

    Posté par  (Mastodon) . Évalué à 4.

    Je ne sais pas trop ce que tu cherches comme info et ce que tu connais déjà, mais il existe une méthode relativement simple pour créer un système de plugins "à la main", ce sont les bibliothèques dynamiques (dll sous windows, .so sous linux).

    La marche à suivre est la suivante: on définit une interface entre le plugin et le soft, sous la forme suivante:
    1- une liste de fonctions que le plugin doit définir
    2- une liste de fonctions du soft que le plugin peut appeler
    3- des structures de données et éventuellement si on code malproprement, des variables globales.

    Ensuite, pour charger un plugin, il suffit d'ouvrir le .so correspondant (avec dlopen) et de charger les symbole définis en 1. Typiquement, si on code en C, on va avoir un objet (structure) de type Plugin, comportant une liste de champs qui sont tous des pointeurs vers les fonctions de 1:
    typedef struct _f {
    int (*init)(arg1, arg2;
    void (*unload)(void);
    ...
    } Plugin;

    ensuite on appelle les fonctions de son plugin comme ça:
    Plugin *p = ma_fonction_qui_charge_un_plugin(...);
    p->init(1, 2);
    p->mon_calcul(...);


    On code son plugin comme si c'était un module normal du logiciel, en appelant les fonctions définies en 2 lorsqu'on en a besoin. Comme elles sont définies 'extern', on n'a pas besoin d'avoir le soft pour coder le plugin, on a juste besoin de l'interface.

    Pour info, GLib propose une abstraction à dlopen qui devrait être plus portable (marcher par exemple sous Windows), et qui s'appelle, si je me souviens bien, g_module.

    Dans d'autres langages c'est souvent encore plus simple. Par exemple en Java un plugin peut se résumer à un ensemble de classes implémentant une interface standardisée, que l'on charge avec un ClassLoader au runtime. Pareil en ruby et autres.

    • [^] # Re: Méthode artisanale

      Posté par  . Évalué à 3.

      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.)

  • # OSGi

    Posté par  . Évalué à 2.

    http://www.osgi.org/osgi_technology/index.asp?section=2
    Cette spécification est le résultat d'un consortium
    http://www.osgi.org/
    et elle est à la base du projet Eclipse

    Seule contrainte c'est du Java

  • # Plugins et licences

    Posté par  (site web personnel) . Évalué à 1.

    Merci pour ces infos, je vais regarder.

    Y a-t-il également des techniques pour permettre une certaine liberté dans le choix de la licence des plugins ?

    Par exemple, si mon application principale est GPL ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.