Système de plugins

Le cœur de Doconut reste léger ; les fonctionnalités optionnelles sont livrées sous forme de plugins — des packages NuGet séparés qui ajoutent des visualiseurs ou des services et sont activés par votre licence. Cette page explique le modèle d’enregistrement, le fonctionnement du filtrage de licence à l’exécution, et comment brancher votre propre visualiseur.

Ce modèle est nouveau dans cette version. La bibliothèque .NET Standard précédente ne disposait d’aucun registre de plugins : la conversion était intégrée au visualiseur lui‑-même et les licences de plugins étaient installées via des appels statiques Viewer.SetLicensePlugin(...). Aucun de ces mécanismes n’est un enregistrement ici.

Enregistrement d’un plugin

Chaque package de plugin expose une classe de plugin. Vous l’enregistrez une fois, au démarrage :

builder.Services.AddDoconut(options =>
{
    options.AddPlugin<Doconut.Plugins.Converter.ConverterPlugin>();
    options.AddPlugin<Doconut.Plugins.Dicom.DicomPlugin>();
});

AddPlugin<TPlugin>() instancie le plugin et invoque son rappel Register contre le registre de plugins détenu sur DoconutOptions. Tout ce qu’un plugin apporte est étiqueté avec la capacité requise du plugin. AddDoconut() valide les plugins enregistrés immédiatement : une licence manquante, un fichier legacy TRIAL, ou une licence payante sans la capacité provoquent un échec du démarrage avec InvalidOperationException. Un enregistrement Temporaire/Démo est conservé au‑delà de l’expiration, mais ses capacités d’exécution sont révoquées après la date d’expiration.

Le contrat

Un plugin implémente une interface délibérément petite :

public interface IDoconutPlugin
{
    string Name { get; }                          // ex. "Doconut DICOM Viewer"
    LicenseCapability RequiredCapability { get; } // la porte de licence
    void Register(IDoconutPluginBuilder builder); // contribuer aux visionneurs/services
}

À l’intérieur de Register, le constructeur accepte deux types de contributions :

• builder.RegisterViewer(".dcm", () => new DicomViewer()) — un visualiseur pour une extension de fichier,
• builder.RegisterService<TContract>(() => …) — un service typé que d’autres parties du pipeline peuvent rechercher.

Capacités et filtrage

Les capacités sont les unités de licence. Converter et Dicom sont fournis comme plugins optionnels ; Search et Annotation sont des fonctionnalités intégrées filtrées de la même manière. Le visualiseur de base n’est pas une capacité — c’est le prérequis, exposé comme IsViewerLicensed sur le service de licence.

La validation au démarrage empêche normalement un plugin non licencié d’entrer dans le pipeline de requêtes. La fabrique de visualiseurs applique également deux règles d’exécution défensives, importantes si les droits changent après le démarrage :

• Le plugin remplace un visualiseur intégré (un plugin revendique une extension que le registre intégré gère également) : avec la capacité licenciée, le visualiseur du plugin l’emporte ; sans elle, Doconut revient silencieusement au visualiseur intégré. Les utilisateurs voient toujours leur document — ils n’obtiennent simplement pas la fonctionnalité du plugin.
• Format uniquement plugin (par ex. .dcm — DICOM n’a pas de visualiseur intégré) : sans la capacité, l’appel d’ouverture échoue brutalement :

LicenseException: This document type requires the 'Dicom' plugin license.

Une licence Temporaire active accorde toutes les capacités (avec une visualisation de base propre, sans filigrane). C’est une source classique de surprises lors du lancement : enregistrer les mêmes plugins avec une licence achetée qui omet l’une de leurs capacités fait échouer AddDoconut() au démarrage. Comparez IsCapabilityGranted(...) à votre plan avant le déploiement. À l’inverse : avec aucune licence du tout, rien n’est accordé — une licence manquante n’est pas une licence Temporaire.

Le même filtrage apparaît côté client : Viewer.ReferenceScripts() et ReferenceCss() émettent les paquets script/style pour les fonctionnalités filtrées par licence (recherche, annotation, …) uniquement lorsque la licence les active, de sorte que l’interface du widget reste cohérente avec ce que le serveur fera réellement.

Carte des fonctionnalités et des plugins

L’interface du produit utilise « plugin » comme un libellé de fonctionnalité large, mais l’enregistrement côté serveur diffère :

L’annotation et la Recherche normale n’utilisent pas AddPlugin<TPlugin>() ; leurs paquets sont émis uniquement lorsque la licence accorde la capacité correspondante. Convertisseur et DICOM sont les implémentations opt‑in IDoconutPlugin publiées pour cet ensemble de documentation.

Les artefacts .NET Standard approuvés contiennent Doconut.NETStandard.Converter et Doconut.NETStandard.Dicom à la même version que le package principal.

Packages de plugins publiés

Chaque possède une page dédiée sous Plugins avec sa configuration et son utilisation.

Visualiseurs personnalisés — votre propre gestionnaire de format

Vous pouvez brancher un visualiseur dans le pipeline sans écrire de package de plugin, directement depuis Program.cs :

builder.Services.AddDoconut(options =>
{
    options.RegisterViewer(
        ".myext",
        () => new MyCustomViewer(),               // implémente IFormatViewer
        () => new ImageConfig { ImageResolution = 150 }); // configuration par défaut optionnelle
});

Les visualiseurs personnalisés ont la priorité sur tout — intégrés et plugins confondus — et ne sont pas filtrés par licence (c’est votre code). La fabrique revient à un(e) ImageConfig lorsque vous ne fournissez pas de configuration par défaut.

Points clés

• Les plugins sont enregistrés explicitement et leur LicenseCapability est validé pendant AddDoconut() — une autorisation manquante ou insuffisante non temporaire échoue rapidement.
• Les plugins de type remplacement se dégradent gracieusement ; les formats uniquement plugin échouent avec un(e) LicenseException.
• Une licence Temporaire active débloque tout ; la production débloque ce que vous avez acheté. Vérifiez avec IDoconutLicenseService avant la mise en production.