Skip to end of metadata
Go to start of metadata

Chat Log - 2006 01 03
23:42 - souk
ben deja, tout ce dont on avait parle:

  • pas seulement installed/uninstalled, mais aussi deployed et undeployed pour le status des plugin
    • uninstalled et installed ne servent a rien comme status en fait, vu qu'un plugin uninstalled n'est ni dans le store ni dans la registry et un plugin installed est un plugin dans le store
    • les events/callback en eux memes peuvent être interessants, mais pas le status, de fait
    • en revanche, il faut un mechanisme pour stocker le status des plugins qui sont dans le store (deployed/undeployed)
    • c'est tout à fait pour ça que j'avais parlé des events deploy/undeploy(wink)
  • il peut y avoir plusieurs type de plugins par registry pour eliminer la necessite d'avoir n registries pour n types de plugins
  • gestion des dependances interplugin
  • mechanisme d'injection de plugin dans d'autres plugins par annotations => j'essplique

    genre un plugin a besoin d'un autre plugin au moment de son instanciation, on annote un setter de telle facon que la registry peut injecter le plugin voulu

    genre:
    @InjectPlugin(family="truc",plugin="bidule")
    public void setBidule(Bidule bidule){
    ...
    }
  • revoir toutes les exceptions, leurs constructeurs, voir si on peut pas en passer en unchecked
    • moi je dis qu'on peut dawa

23:47 - greg
je vois pas à quoi va servir l'annotation, l'injection pourrait etre déjà gérée par spring ou pico ou autre

23:49 - souk

  • l'autowiring a peu de chances de fonctionner s'il y a plein de plugin de meme type

23:50 - greg
ben tu mets une dep sur le type concret

23:51 - souk
2) je veux pas dependre de spring ou pico ou autre
j'essaierai de te trouver un exemple demain


Types de plugins:

  • On a besoin de "metadata" differents pour chaque type de plugin. La solution cra-cra adoptée par Tonic, c'est de passer un Element dom au builder/deployer/whatever. Solution plus propre: modéliser ça dans des beans. . Suis tenté de jeter un oeil à modello (cfr maven2 qui génère ses classes de model depuis un genre d'xsd, ce qui permet aussi de generer de la doc etc...). Ca n'implique pas necessairement une dépendence sur un format xml, mais ça pourrait etre une des possibilités les plus simples pour les users? On pourrait meme probablement générer un xsd qui supporterait tous les types de plugins qu'on fournirait - tout en laissant la possibilité aux users d'utiliser / implementer les types de plugins de leur choix.
  • No labels