En direct du Minnesota
Ces jours-ci, la mention «live from the Minnesota Search Sprint» (en direct du sprint de recherche du Minnesota) apparaît régulièrement en en-tête des soumissions de modifications apportées au moteur de recherche de Drupal.
En effet, tel que je l’avais annoncé récemment, une petite équipe de programmeurs (Earnest Berry, Robert Douglass, Chad Fennell, Doug Green, Djun Kim, Blake Lucchesi et moi-même) se trouve maintenant en plein «sprint» de programmation pour enrichir le module search de Drupal. Notre centre d’opérations se trouve sur l’immense campus de l’Université du Minnesota à Minneapolis, où Chad Fennell a gentiment pris soin de la logistique.
Notre principal défi consiste à atteindre un bon équilibre entre les réalisations concrètes et la vision globale du projet. Établir une feuille de route pour l’avenir est important, mais dans l’univers du logiciel libre, la seule chose vraie c’est le code! Les plans à long terme sont particulièrement difficiles à tenir dans cet univers, puisque Drupal évolue avec les disponibilités des contributeurs et les priorités des projets qui financent leur travail. La vélocité même du développement de Drupal en fait une cible particulièrement mouvante.
Par conséquent, ces deux derniers jours nous avons alterné entre la réalisation de tâches simples (pour les résultats concrets) et les remue-méninges (pour les enjeux de plus grande envergure), avec un souci d’aligner même les tâches mineures sur les objectifs plus importants, histoire d’aller dans la bonne direction, petit pas par petit pas. Il s’agit d’un réel puzzle; des pièces insignifiantes en elles-mêmes prendront, une fois accolées aux autres, tout leur sens.
Quelques pistes…
Voici quelques-unes des pistes que nous explorons dans ce sprint :
- Unification du processus d’analyse lexicale appliqué à l’indexage et lors de la recherche.
- Analyse lexicale au moyen d’une chaîne de traitements personnalisable, basée sur la même architecture que les filtres d’entrée de Drupal.
- Varier l’analyse lexicale en fonction de paramètres tels la langue ou le format du contenu. Par exemple, des algorithmes de lexémisation distincts s’appliqueraient en fonction de la langue.
- Calcul de classement des résultats extensible. Hormis les facteurs de base déjà prévus pour établir le classement des résultats, de nouveaux facteurs pourront être programmés dans des modules tiers et activés à la demande par l’administrateur d’un site. Par exemple, un site de commerce électronique pourrait rehausser le classement d’un produit en fonction de son volume de ventes.
- Possibilité d’activer ou de désactiver différents modules de recherche séparément. Dans Drupal 5 et 6, activer le module search active toutes les fonctions de recherche, sur les noeuds et les utilisateurs, même si toutes ne sont pas pertinentes au site.
- Abstraire la représentation des résultats pour éventuellement permettre la construction de facettes à partir d’un ensemble arbitraire de noeuds, qu’ils proviennent, par exemple, d’une recherche ou d’une vue.
- Utiliser un objet plus «intelligent» qu’une chaîne de caractères pour représenter la requête, tout au long du processus de recherche. Cet objet pourrait être construit via une interface de programmation (accessible à n’importe quel module) ou via une chaîne de caractères. Il pourrait également produire la chaîne de caractères qui lui correspond en sortie, pour génération d’hyperliens. Présentement, les modules Faceted Search et ApacheSolr ont tous deux des éléments qui s’approchent de ceci. Ultimement, si cet objet pouvait représenter une requête du module Views, un grand pas serait accompli pour que des facettes puissent se rattacher directement à une vue…
- Scinder la logique d’indexation de la logique de recherche. Les fonctions de recherche de base sont un fardeau inutile pour les site utilisant Faceted Search ou les filtres de recherche de Views 2 — ces modules utilisent l’index de base, mais implémentent leur propre logique de recherche.
- Unifier la recherche d’éléments hétérogènes dans une seule page de résultats. Ceci pourrait rendre particulièrement utile l’éventuelle indexation d’éléments comme les blocs, les vues (du module Views) et les panneaux (du module Panels).
- Indexer des données qui sont présentement omises de l’index afin d’augmenter la pertinence des résultats : Chemin (URL) du contenu, nom de l’élément de menu associé au contenu, etc.
- Abstraire le système d’indexation des contenus afin de pouvoir lui substituer l’indexation par un moteur externe, par exemple Solr ou Sphinx.
Participer, en savoir plus…
Que vous soyez sur place ou non, il est facile de participer à ces travaux ou de les suivre de plus près! Il suffit d’examiner les propositions, les réviser, les tester, les commenter!
Demain sera, déjà, la dernière journée du sprint. En plus de poursuivre certaines des pistes présentées ci-haut, nous comptons examiner les questions de performance d’exécution. À suivre!
Commentaires