🌍
Français
Fiche
| Niveau de difficulté : | Avoir des connaissances. |
|---|---|
| Recommandations : | n/c. |
| A lire aussi : | n/c |
Inspirez-vous aussi de ce qui existe déjà.
:!:Les informations de cette page s'appliquent à partir de la branche 1.5
Version 1, discussion dédiée sur le forum La fonctionnalité de notification existe depuis la branche 1.2. Le mail est la méthode utilisée pour notifier l'ajout d'un commentaire ou l'upload d'un nouvel élément. Une entrée dans l'outil de suivi de bogues décrit l'origine de cette spécification.
En prenant en compte les permissions de chaque utilisateur (chaque utilisateur n'accède qu'à une liste de N catégories, N < nombre total de catégories), les informations notifiées sont les suivantes :
Pour un administrateur, les informations supplémentaires sont :
Attention/ : pour chaque information, s'il n'y a rien à notifier alors pas de notification. S'il n'y a pas de nouveaux commentaires, alors aucune information concernant les nouveaux commentaires n'apparaît. Vous ne trouverez pas de message du type “0 nouveau commentaire”.
La notification ne se réalise plus par mail mais par flux RSS à partir de la branche 1.5. (Note: la version 1.6 a vu le retour de la notification_par_mail). Concrètement, chaque utilisateur récupère une adresse de flux RSS avec un identifiant unique, permettant d'adapter les informations notifiées à chaque utilisateur.
L'adresse du flux se récupère sur l'écran de notification, accessible dans le menu sur la page des miniatures.
L'adresse du flux doit être enregistrée dans un lecteur de flux. Un peu de publicité pour des outils réalisant ce travail :
Grâce au mécanisme des flux RSS, c'est l'utilisateur qui décide à quelle fréquence il décide d'être informé des nouvelles. Lors de l'enregistrement du flux, la plupart des lecteurs de flux proposent soit une mise à jour automatique toutes les X minutes, soit uniquement des mises à jour du flux à la demande.
Un message n'est placé dans le flux RSS que s'il y a des informations à notifier. Donc si entre 2 lectures du flux RSS il n'y a rien de nouveau, alors aucun message n'est généré. Ce mécanisme évite de surcharger inutilement vos lecteurs de flux RSS.
Compléments d'information :
Le mail n'est pas très commode pour notifier les utilisateurs, pour plusieurs raisons :
mail() pas toujours présenteUne tendance actuelle du web est la syndication des informations sous forme de flux RSS. Cette méthode est généralement utilisée pour publier des articles, mais elle peut s'étendre à bien d'autres utilisations. PhpWebGallery pourrait l'utiliser pour gérer la notification.
Comme décrit précédemment, les informations notifiées dépendent des permissions de l'utilisateur : si user1 accède à la catégorie privée cat1 mais que user2 n'y accède pas, alors seul user1 pourra être notifié des informations concernant cat1. Le flux RSS dépend donc de l'utilisateur qui s'y connecte.
Mon niveau (celui de Pierrick) de connaissance actuelle me laisse penser que l'authentification sur un flux RSS est possible mais pas supporté par tous les lecteurs de flux (edit : en fait, il s'agit de l'authentification comme celle mise à disposition par Apache par .htaccess, pour simplifier. Ceci confirme que cette méthode ne peut pas être systématiquement utilisée). Il est donc préférable d'authentifier l'utilisateur par une variable dans l'URL. L'identifiant de l'utilisateur n'est pas suffisant en terme de sécurité. A l'image d'un identifiant de session, qui lie temporairement une connexion à un utilisateur, un identifiant de flux peut lier définitivement (pas temporaire en somme) une connexion à un utilisateur. Le caractère définitif de l'identifiant de flux implique un identifiant plus “long” (disons 50 caractères). Cela dit, le niveau de sécurité requit pour l'accès à un flux est largement moindre que celui d'une session. En effet, le flux ne permet que de notifier, il ne s'agit pas de présenter du contenu directement dans le flux.
L'information la plus intéressante est certainement : ”que s'est il passé depuis la dernière fois ?”. Ceci implique donc que PhpWebGallery retienne la date du dernier relevé pour chaque utilisateur enregistré.
La réponse à cette question n'est valable que si la même personne exploite le flux, ce qui ne peut pas être possible dans le cas des utilisateurs qui parcourent la galerie anonymement. Il faut prévoir un mécanisme de notification par période fixe. Par exemple, si la période est fixée à 1 jour, à chaque requête, le flux retournera 10 blocs d'informations : ”nouveautés entre le 1er juillet 2005 00:00 et le 1er juillet 2005 23:59”, ”nouveautés entre le 2 juillet 2005 00:00 et le 2 juillet 2005 23:59”, etc.
L'inconvénient concernant la méthode de fréquence fixe, c'est que les nouvelles informations ne peuvent être notifiées qu'une fois la période en cours terminée. Prenons l'exemple d'une période fixe de 1 jour. Si je questionne le flux à 15h00 et qu'il m'informe qu'il y a eu des nouveautés entre le 00:00 et 15:00, que doit envoyer le flux si je l'interroge à nouveau à 16:00 ?
L'idéal serait que pour le choix de la fréquence (fixe ou selon le dernier relevé) soit possible pour chaque utilisateur, ainsi que la valeur de la période fixe lorsque cette méthode est choisie (1 semaine, 1 jour, 1 heure).
La fonctionnalité de notification impose une plus grande précision sur la notion de temps. L'information date de mise à disposition d'un élément n'est précise qu'au jour près (le champ images.date_available est de type date). Cette précision doit être descendu à la seconde près (type datetime).
Un exemple devrait être suffisamment parlant :
titre (méthode fréquence variable) : nouveautés au 1er juillet 2005 15:42
titre (méthode fixe, période = 1 heure) : nouveautés entre le 1er juillet 2005 00:00 et le 1er juillet 2005 01:00
contenu :
Une fois notifié, l'utilisateur peut consulter les éléments récents de la galerie grâce aux pages “images récentes”, “catégories récentes” et la page des commentaires. Une évolution serait de donner l'URL des catégories mises à jour par exemple, mais c'est secondaire.