Partager via

Implémentation d’un gestionnaire de protocole pour WDS

  • Article

Notes

Windows Desktop Search 2.x est une technologie obsolète qui était initialement disponible en tant que complément pour Windows XP et Windows Server 2003. Sur les versions ultérieures, utilisez plutôt Recherche Windows .

La création d’un gestionnaire de protocoles implique l’implémentation d’ISearchProtocol pour gérer les objets UrlAccessor, IUrlAccessor pour générer des métadonnées sur et d’identifier les filtres appropriés pour les éléments du magasin de données, IProtocolHandlerSite pour instancier un objet SearchProtocol et identifier les filtres appropriés, et IFilterpour filtrer les fichiers propriétaires ou pour énumérer et filtrer les fichiers stockés hiérarchiquement. Le gestionnaire de protocole doit être multithread.

Cette section contient les rubriques suivantes :

Remarque sur les URL

Recherche de bureau Microsoft Windows (WDS) utilise des URL pour identifier de manière unique des éléments dans un système de fichiers, à l’intérieur d’un magasin semblable à une base de données ou sur le Web. Une URL qui définit un nœud d’entrée est appelée page de démarrage ; WDS commence à cette page d’accueil et analyse de manière récursive le magasin de données. La structure d’URL classique est la suivante :

protocol://host/path/name.extension

Notes

Lorsque vous souhaitez ajouter un nouveau magasin de données, vous devez sélectionner un nom pour l’identifier qui n’entre pas en conflit avec les magasins actuels. Nous vous recommandons cette convention de nommage : companyName.scheme.

 

Interfaces de gestionnaire de protocole

ISearchProtocol

L’interface ISearchProtocol appelle, initialise et gère les objets UrlAccessor. Pour plus d’informations sur l’implémentation de l’interface ISearchProtocol, consultez Informations de référence sur l’interface ISearchProtocol.

IUrlAccessor

Pour une URL spécifiée, l’interface IUrlAccessor génère des métadonnées sur la structure d’emplacement ainsi que sur les éléments contenus, et elle lie ces éléments à un filtre. L’objet IUrlAccessor est instancié et initialisé par un objet SearchProtocol ; Toutefois, vous pouvez également implémenter une méthode d’initialisation interne afin que votre objet IUrlAccessor puisse effectuer des tâches d’initialisation spécifiques à votre gestionnaire de protocole, telles que la validation de l’URL d’un élément accessible ou la vérification de la dernière heure de modification pour déterminer si un fichier doit être traité dans l’analyse en cours.

Notes

Les heures modifiées pour les répertoires sont ignorées. L’objet IUrlAccessor doit énumérer les objets enfants pour déterminer s’il y a eu des modifications ou des suppressions.

 

Une grande partie de la conception de l’objet UrlAccessor dépend du fait que la structure soit hiérarchique ou basée sur des liens. Pour les magasins de données hiérarchiques, l’objet UrlAccessor doit trouver un filtre qui peut énumérer son contenu. Une autre distinction entre les gestionnaires de protocole hiérarchiques et basés sur des liens est l’utilisation de la méthode IsDirectory. Dans les gestionnaires de protocoles basés sur des liens, cette méthode doit retourner S_FALSE. Les gestionnaires de protocoles hiérarchiques doivent retourner S_OK pour les conteneurs.

Pour obtenir des instructions supplémentaires sur l’implémentation d’une interface IUrlAccessor , consultez les informations de référence sur l’interface IUrlAccessor .

IProtocolHandlerSite

Cette interface est utilisée pour instancier un objet SearchProtocol et fournit également à l’objet UrlAccessor un filtre approprié pour un ID de classe (CLSID) spécifié.

IFilters pour conteneurs

Si vous implémentez un gestionnaire de protocole hiérarchique, vous devez implémenter un composant IFilterde conteneur qui énumère les URL représentant des conteneurs ou des dossiers. Le processus d’énumération est une boucle via les méthodes GetChunk et GetValue de l’interface IFilter qui retourne une liste d’URL qui représentent chaque élément dans le conteneur.

Tout d’abord, GetChunk retourne un FULLPROSPEC avec la propriété définie GATHER_PROPSET et :

  • PID_GTHR_DIRLINK, l’URL de l’élément sans l’heure de la dernière modification, ou
  • PID_GTHR_DIRLINK_WITH_TIME, l’URL ainsi que l’heure de la dernière modification

Le GUID du jeu de propriétés pour GATHER_PROPSET est 0B63E343-9CCC-11D0-BCDB-00805 CCNE04. La propriété PROPSPEC est PID_GTHR_DIRLINK=2 ou PID_GTHR_DIRLINK_WITH_TIME = 12 décimales.

Le renvoi PID_GTHR_DIRLINK_WITH_TIME est plus efficace, car l’indexeur peut déterminer immédiatement si l’élément doit être indexé sans appeler les méthodes ISearchProtocol-CreateUrlAccessor>() et IUrlAccessor-GetLastModified>().

GetValue retourne ensuite un PROPVARIANT pour l’URL (et l’heure de la dernière modification si elle est utilisée), comme suit :

  • VT_LPWSTR, l’URL de l’élément enfant, ou
  • Vecteur de l’URL suivi d’un FILETIME

L’exemple de code suivant montre comment générer le PID_GTHR_DIRLINK_WITH_TIME approprié.

Notes

CE CODE ET CES INFORMATIONS SONT FOURNIS « TELS QUELS » SANS GARANTIE D’AUCUNE SORTE, EXPRESSE OU IMPLICITE, Y COMPRIS, MAIS SANS S’Y LIMITER, LES GARANTIES IMPLICITES DE QUALITÉ MARCHANDE ET/OU D’ADÉQUATION À UN USAGE PARTICULIER.

Copyright (C) Microsoft. All rights reserved.

 

// params are assumed to be valid

HRESULT GetPropVariantForUrlAndTime(PCWSTR pszUrl, const FILETIME &ftLastModified, PROPVARIANT **ppPropValue)
{
    *ppPropValue = NULL;

    // allocate the propvariant pointer
    *ppPropValue = (PROPVARIANT *)CoTaskMemAlloc(sizeof(*ppPropValue));
    HRESULT hr = *ppPropValue ? S_OK : E_OUTOFMEMORY;

    if (SUCCEEDED(hr))
    {
        PropVariantInit(*ppPropValue);  // zero init the value

        // now allocate enough memory for 2 nested PropVariants.
        // PID_GTHR_DIRLINK_WITH_TIME is an array of 2 PROPVARIANTs
        PROPVARIANT *pVector = (PROPVARIANT *)CoTaskMemAlloc(sizeof(*pVector) * 2);
        hr = pVector ? S_OK : E_OUTOFMEMORY;

        if (SUCCEEDED(hr))
        {
            // set the container PROPVARIANT that it is a vector of 2 PROPVARIANTS
            (*ppPropValue)->vt = VT_VARIANT | VT_VECTOR;
            (*ppPropValue)->capropvar.cElems = 2;
            (*ppPropValue)->capropvar.pElems = pVector;
            PWSTR pszUrlAlloc;
            hr = SHStrDup(pszUrl, &pszUrlAlloc);

            if (SUCCEEDED(hr))
            {
                // now fill the array of PROPVARIANTS
                // put the pointer to the URL into the vector
                (*ppPropValue)->capropvar.pElems[0].vt = VT_LPWSTR; 
                (*ppPropValue)->capropvar.pElems[0].pwszVal = pszUrlAlloc;

                 // put the FILETIME into vector
                (*ppPropValue)->capropvar.pElems[1].vt = VT_FILETIME; 
                (*ppPropValue)->capropvar.pElems[1].filetime = ftLastModified;
            }

            else
            {
                CoTaskMemFree(pVector);
            }
        }
 
        if (FAILED(hr))
        {
            CoTaskMemFree(*ppPropValue);
            *ppPropValue = NULL;
        }
    }
    return S_OK;
}

Notes

Un composant IFilterde conteneur doit toujours énumérer toutes les URL enfants même si les URL enfants n’ont pas changé, car l’indexeur détecte les suppressions via le processus d’énumération. Si la sortie de date dans un DIR_LINKS_WITH_TIME indique que les données n’ont pas changé, l’indexeur ne met pas à jour les données pour cette URL.

 

L’URL physique est l’URL que l’objet UrlAccessor traite. Si le filtre n’émet pas de DisplayUrl convivial, WDS affiche l’URL physique de l’utilisateur dans le cadre des résultats de la recherche. Le schéma WDS contient deux propriétés pour contrôler ce qui est affiché à l’utilisateur final, comme indiqué dans le tableau ci-dessous.

GUID PROPSPEC Description
D5CDD505-2E9C-101B-9397-08002B2CF9AE DisplayFolder Chemin du dossier affiché à l’utilisateur dans les résultats de la recherche
D5CDD505-2E9C-101B-9397-08002B2CF9AE FolderName Nom d’affichage du dossier parent

 

Si votre code n’émet pas de DisplayFolder ou de FolderName, ces valeurs sont calculées à partir de displayUrl. Les barres obliques dans l’URL désignent les conteneurs au sein du magasin ou du système de fichiers.

Ajout de fonctionnalités d’options de gestionnaire de protocole

Pour que votre gestionnaire de protocole dispose d’une page de démarrage par défaut (et de l’URL du nœud d’entrée), vous devez implémenter l’interface ISearchProtocolOptions . Dans les versions ultérieures de WDS, cette interface fournira des hooks à la boîte de dialogue Options pour une expérience utilisateur améliorée. Cette interface fournit les fonctionnalités suivantes :

  • Détermine si les conditions requises pour votre gestionnaire de protocole sont remplies. Par exemple, le magasin de votre gestionnaire de protocoles peut nécessiter l’accès à une application donnée pour indexer correctement les données de l’application, mais cette application n’est pas disponible.
  • Identifie les exigences minimales dont votre gestionnaire de protocole a besoin pour traiter un élément. Les exigences peuvent être exprimées dans une description conviviale et localisée, telle que « Microsoft Outlook 2000 ou version ultérieure ».
  • Définit les URL que votre gestionnaire de protocole doit traiter par défaut.

ISearchProtocolOptions

Le tableau suivant décrit les méthodes que vous devez implémenter pour l’interface ISearchProtocolOptions .

Méthode Description
CheckRequirements Détermine si les exigences minimales d’un gestionnaire de protocoles personnalisés sont remplies
GetDefaultCrawlScope Retourne une liste d’URL par défaut dans un magasin spécifié pour un gestionnaire de protocole personnalisé
GetRequirements Identifie une description localisée et conviviale de la configuration minimale requise pour un gestionnaire de protocole personnalisé

 

Informations de référence

Notification de l’index des modifications

Ajout d’icônes, d’aperçus et de menus contextuels avec des extensions d’interpréteur de commandes

Installation et inscription de gestionnaires de protocole