Préambule
De nombreux logiciels permettent de gérer un annuaire. Chaque annuaire gère des données différentes en fonction des besoins de ces utilisateurs. Il existe des annuaires très simples comme il en existe de très sophistiqués. Cependant, les données nécessaires pour gérer des newsletters sont assez limitées :
Nom complet de la personne
Adresse électronique avec éventuellement des adresses secondaires en cas d’erreur
Langues parlées (suivant un ordre de préférence)
Envoyer des newsletters (ou tout autre mailing d’information) est un besoin courant quand on gère un annuaire. Malheureusement, les outils existants de newsletters ou de mailing-list ont rarement été réfléchis pour être interopérable de façon simple avec des annuaires déjà existants. Leur utilisation demande souvent de saisir à nouveau les informations et, lorsqu’il existe des mécanismes d’importation des données, c’est au niveau de la mise à jour et de la synchronisation que le problème se pose.
L’intérêt manifesté par la FPH pour le développement proposé par Orus d’un outil de Newsletter qui serait effectué par Conglomedia repose sur le besoin suivant :
disposer d’un logiciel de gestion de newsletter (et plus largement d’envois d’emails) dont les données se mettent à jour régulièrement à partir de données issues d’annuaires existants.
Cette mise à jour se ferait par l’intermédiaire de fichiers XML que l’outil d’administration de la Newsletters est capable de récupérer afin de mettre à jour ses propres données.
Principe de fonctionnement de la mise à jour
Le principe est très proche de celui de la syndication et des flux RSS, à savoir :
les logiciels d’annuaire génèrent à intervalles réguliers un fichier XML (le format XML sera discutée plus loin), ces fichiers sont accessibles via une URL (par exemple, http://www.fph.ch/annu.xml)
le Générateur de Newsletter possède un système d’abonnement où on indique les URLs des fichiers XML qu’il doit visiter
À intervalles réguliers (ou à la demande de l’administrateur), le Générateur visite les différents URLs auxquelles il est abonné. S’il constate que le fichier a changé (en se basant sur la date par exemple), il charge le contenu de ce fichier et met à jour ses données.
Dans un premier temps, nous allons considérer qu’un Générateur de Newsletter ne mélange pas les données de différents annuaires.
Principe du format XML
Comme il n’existe pas de standards simples de gestion d’un annuaire, nous allons construire notre propre format XML de transfert de données.
Ce format XML va contenir les données sur les personnes (appelées « contact ») , à savoir ce qui a été décrit plus haut :
Nom complet de la personne
Adresse électronique avec éventuellement des adresses secondaires en cas d’erreur
Langues parlées (suivant un ordre de préférence)
A ces données de base qui devront toujours être présentes, le format devra offrir la possibilité d’indiquer des critères supplémentaires (correspondant aux variables illimités et programmables du module 2)). Ces critères permettront d’affiner les envois.
Chaque personne devra posséder un identifiant unique, stable (autrement dit, entre différentes mises à jour, l’identifiant d’un même contact devra rester le même), ce qui facilitera certaines synchronisation.
Voici un exemple très simple avec deux contacts :
<?xml version='1.0' encoding='UTF-8'?>
<contacts>
<contact contact-id="contact1">
<full-name>Juan Luis Ulluoa</full-name>
<emails>
<email>juanulloa@voila.fr</email>
</emails>
<langs>
<lang>es</lang>
<lang>fr</lang>
</langs>
</contact>
<contact contact-id="contact2">
<full-name>Vincent Calame</full-name>
<emails>
<email>vincent.calame@exemole.fr</email>
<email>vincent@alliance21.org</email>
</emails>
<langs>
<lang>fr</lang>
<lang>en</lang>
</langs>
</contact>
</contacts>
Cet exemple reprend toutes les données essentielles. l’ordre des éléments <email> et <lang> indique l’ordre de préférence (d’abord envoyer au premier email dans la première langue indiquée).
Le deuxième exemple est complet avec la définition des champs supplémentaires :
<?xml version='1.0' encoding='UTF-8'?>
<contacts>
<metadata>
<field-metadata name="lists" value-type="multiple"/>
<field-metadata name="country" value-type="unique"/>
</metadata>
<contact contact-id="contact1">
<full-name>Juan Luis Ulluoa</full-name>
<emails>
<email>juanulloa@voila.fr</email>
</emails>
<langs>
<lang>es</lang>
<lang>fr</lang>
</langs>
<value field-name="country">CL</value>
<value field-name="lists">ADMIN</value>
<value field-name="lists">INFO-ORUS</value>
<value field-name="lists">FPH</value>
</contact>
<contact contact-id="contact2">
<full-name>Vincent Calame</full-name>
<emails>
<email>vincent.calame@exemole.fr</email>
<email>vincent@alliance21.org</email>
</emails>
<langs>
<lang>fr</lang>
<lang>en</lang>
</langs>
<value field-name="country">FR</value>
<value field-name="lists">ADMIN</value>
</contact>
</contacts>
Les différences sont les suivantes. Premièrement,un élément <metadata> placé au début permet d’indiquer les champs supplémentaires. Un champ est défini par l’élément <field-metadata> qui a deux attributs :
@name : qui est le nom du champ.
@value-type : qui indique si la valeur est unique (le champ ne peut avoir qu’une seule valeur) ou s’il y a plusieurs valeurs possibles (option « multiple »).
Ensuite, au niveau de chaque contact, la valeur des champs est indiqué par un élément <value> qui a comme attribut @field-name, le nom du champ. Lorsqu’un champ est de type « multiple », il peut y avoir plusieurs éléments <value> à la suite.
Dans notre exemple, nous avons défini dans <metadata> deux champs :
un champ country qui prend une valeur unique indiquant le pays de la personne (en l’occurence le code ISO du pays)
un champ lists indiquant les différentes listes définies dans l’annuaire auxquelles appartient la personne.
Dans notre exemple, Juan Luis Ulluoa est du Chili (code CL) et est inscrit aux listes ADMIN (la liste des administrateurs), INFO-ORUS (la lettre d’information ORUS) et FPH (la lettre d’information FPH). Vincent Calame est en France (code FR) et n’est inscrit qu’à ADMIN.
Ainsi, l’Administrateur doit pouvoir offrir la possibilité d’envoyer un email aux inscrits à a liste INFO-ORUS habitant le Chili pour leur indiquer par exemple une information locale (conférence d’Alfredo Pena-Vega dans une université de Santiago par exemple).