Piwigo.org

plg · 2005-06-23 00:07:41

Bonjour à tous,

Le principe est le suivant : à partir d'une page dans le wiki, nous discutons dans le présent topic sur le thème de la page du wiki (ajouts, modifications, suppressions...). La page du wiki sera modifiée (par moi ou n'importe qui, telle que le wiki le permet) pour tenir compte de la discussion.

Page du wiki : Specifications, branche 1.5, Notification.

Bonne lecture et merci de donner votre avis, vos idées.

plg · 2005-06-23 00:10:03

Premier point à débattre, extrait de la version 1, sur le wiki :

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 ?

* Soit le bloc d’information à comme titre “nouveautés entre le 1er juillet 2005 00:00 et 1er juillet 2005 23:59" quelque soit l’heure de vérfication du flux dans la journée du 1er juillet et PhpWebGallery met à jour le contenu du bloc si des nouveautés sont apparues entre 15:00 et 16:00.

* Soit le bloc d’information passe du titre “nouveautés entre le 1er juillet 2005 00:00 et 1er juillet 2005 15:00“ à “nouveautés entre le 1er juillet 2005 00:00 et 1er juillet 2005 16:00“. Il s’agit alors d’un nouveau bloc d’information (considéré comme tel par le lecteur de flux à mon avis), mais le second bloc reprend le contenu du premier.

Merci de votre aide.

plg · 2005-07-06 23:07:50

Je suis en phase de début de développement sur cette fonctionnalité et je me heurte au problème suivant : en considérant un flux à fréquence fixe, le flux n'enverrai pas les mêmes informations en fonction du moment de vérification.

Je m'explique :

Hypothèse 1 : pour connaître le nombre d'éléments ajoutés entre 2 dates, PhpWebGallery recherche parmi les éléments (qui sont apparus entre les 2 dates) associées aux catégories autorisées.

Hypothèse 2 : pour un utilisateur donné, la liste des catégories autorisées varie au cours du temps.

Hypothèse 3 : les éléments peuvent être supprimés (et perdre toute traces dans la base).

Hypothèse 4 : les liens entre éléments et catégories ne sont pas datés.

Je veux en venir au fait que PhpWebGallery n'est pas un gestionnaire de version et qu'il n'est par exemple pas envisageable qu'un utilisateur puisse demander à voir la galerie telle qu'elle était à une date précise avec les autorisations que l'utilisateur avait à cette même date.

Dans ces conditions, il faudra avoir conscience que les informations du flux peuvent être partiellement fausses à cause des modifications non datées et l'absence de trace sur les suppressions (de lien entre élément et catégorie, d'un élément, etc.).

Sur ce, je continue le développement avec un arrière goût de "j'envoie des informations partiellement fausses, mais qui seront vraies et utiles dans 95% des cas.".

plg · 2005-07-16 17:40:25

La build BSF_200507161719 propose une première version du flux de notification RSS. Cette nouvelle fonctionnalité constitue un assez gros développement et va certainement nécessiter pas mal de tests.

Pour répondre à la première question que je me posais initialement, j'ai choisi la 2eme solution, mais ce n'est pas forcément définitif.

timo · 2005-07-17 01:18:02

z0rglub a écrit:
Premier point à débattre, extrait de la version 1, sur le wiki :
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 ?

* Soit le bloc d’information à comme titre “nouveautés entre le 1er juillet 2005 00:00 et 1er juillet 2005 23:59" quelque soit l’heure de vérfication du flux dans la journée du 1er juillet et PhpWebGallery met à jour le contenu du bloc si des nouveautés sont apparues entre 15:00 et 16:00.

* Soit le bloc d’information passe du titre “nouveautés entre le 1er juillet 2005 00:00 et 1er juillet 2005 15:00“ à “nouveautés entre le 1er juillet 2005 00:00 et 1er juillet 2005 16:00“. Il s’agit alors d’un nouveau bloc d’information (considéré comme tel par le lecteur de flux à mon avis), mais le second bloc reprend le contenu du premier.
Merci de votre aide.

Salut,

Moi je dirais les deux. Un choix entre les modifs du jour ou du dernier passage. Laisser à l'utilisateur le choix entre les deux propositions. (On pourrait aussi faire des requêtes entre deux dates, par mois ou années).
1/ Rajout à la table xxxxx_images, en plus du champ date_available un champ time_available.
2/ Rajout d'un champs last_visit_time quelque part dans une table xxxxx ???

Je connais pas trop bien encore la structure, peut être que je dis des anneries. :)

Dernière modification par timo (2005-07-17 01:18:18)

plg · 2005-07-17 10:52:45

timo a écrit:
Moi je dirais les deux. Un choix entre les modifs du jour ou du dernier passage. Laisser à l'utilisateur le choix entre les deux propositions. (On pourrait aussi faire des requêtes entre deux dates, par mois ou années).

Comme je le souligne dans les spécifications :

specifications a écrit:
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.

Donc, pour un flux "authentifié" (c'est à dire avec un identifiant de flux propre à un utilisateur), l'information est par défaut "quoi de neuf depuis mon dernier passage".

timo a écrit:
1/ Rajout à la table xxxxx_images, en plus du champ date_available un champ time_available.

images.date_available est passé du format MySQL date (2005-07-17) à datetime (2005-07-17 10:48:04)

timo a écrit:
2/ Rajout d'un champs last_visit_time quelque part dans une table xxxxx ???

users.last_feed_check (format datetime) a été rajouté. Attention, le champ last_visit va aussi apparaître pour la 1.5, mais n'aura rien à voir avec le flux de notification (voir new since last visit).

timo a écrit:
Je connais pas trop bien encore la structure, peut être que je dis des anneries. :)

Non, ton avis m'informe que ce que j'ai fait correspond à quelque chose d'intuitif. Par contre, tu ne réponds pas du tout à ma question : pour un flux non authentifié et donc forcément un fréquence fixe, comment gérer la vérification du flux à fréquence moindre que la fréquence du flux.

timo · 2005-07-17 11:58:33

Si c'est un visiteur (donc anonyme), il ne peut accèder qu'aux modifs du jour 00:00>23:59 (notification par période fixe).
Si c'est un enregistré, une requête paramétrée (donc au choix).

Ceci implique donc que PhpWebGallery retienne la date du dernier relevé pour chaque utilisateur enregistré.

Oui.

images.date_available est passé du format MySQL date (2005-07-17) à datetime (2005-07-17 10:48:04)

C'était effectivement le plus simple.

.....
comment gérer la vérification du flux à fréquence moindre que la fréquence du flux.

La solution serait (peut être) de stocker dans une table "guest" les IPs + date/time et de les effacés tout les xx jours.
La procédure d'effacement peut-être effectuée lors du passage d'un visiteur pour les enregistrements ultérieurs à xx jours.

Dernière modification par timo (2005-07-17 12:01:15)

plg · 2005-07-17 12:40:54

timo a écrit:
La solution serait (peut être) de stocker dans une table "guest" les IPs + date/time et de les effacés tout les xx jours.

C'est une idée, mais par exemple, concernant l'authentification, j'ai supprimé le contrôle sur l'adresse IP car elle peut changer (très) fréquemment et plusieurs "guest" peuvent être sur la même adresse IP. Bref, l'adresse IP n'est pas une source d'information fiable (donc pas utilisable pour authentifier).

timo · 2005-07-17 14:49:07

Oui c'est vrai.
Ou alors:
l'IP+Nom de l'ordinateur*+Date/Time. (C'est sur que l'invité peut aussi changer d'IP et garder le même *computer name.
Ou un cookie mais c'est pas toujours bien vu voir désactivé.

plg · 2005-07-17 15:11:57

C'est quoi le "Nom de l'ordinateur" ?

En tout cas, pas trop de cookie possible, je rappelle que le client n'est pas un navigateur web mais un lecteur de flux RSS.

Monsieur Dusnob · 2005-08-01 19:30:31

Nouvelle tentative pour ce message qui aurait dû apparaitre sur ce forum il y a quelque temps... Un bug du forum semble-t-il...

-----

z0rglub a écrit:
Premier point à débattre, extrait de la version 1, sur le wiki :
* Soit le bloc d’information à comme titre “nouveautés entre le 1er juillet 2005 00:00 et 1er juillet 2005 23:59" quelque soit l’heure de vérfication du flux dans la journée du 1er juillet et PhpWebGallery met à jour le contenu du bloc si des nouveautés sont apparues entre 15:00 et 16:00.

* Soit le bloc d’information passe du titre “nouveautés entre le 1er juillet 2005 00:00 et 1er juillet 2005 15:00“ à “nouveautés entre le 1er juillet 2005 00:00 et 1er juillet 2005 16:00“. Il s’agit alors d’un nouveau bloc d’information (considéré comme tel par le lecteur de flux à mon avis), mais le second bloc reprend le contenu du premier.
Merci de votre aide.

Je suis pour la première solution.

Pour les jours précédents, le contenu du bloc d'information est figé. Pour le jour en cours, il est constitué à la volée au moment de la consultation, par interrogation de la base de données.

Après, l'interrogation du flux par un utilisateur qui ne serait pas venu depuis 7 jours pourrait simplement concaténer les blocs d'information des 6 jours précédents + celui du jour en cours à la date d'interrogation. Et ce dans la limite d'un réglage fixé par l'administrateur, ce qui permettrait d'éviter de conserver des blocs d'information en trop grand nombre.

De cette façon, pas besoin d'interroger la base de données pour les jours précédents (gain de temps pour le serveur) puisque les blocs auront déjà été mis en "cache".

Je ne sais pas si c'est faisable ou réaliste, c'est juste une idée :)

Sinon, une référence qui pourrait être utile : l'un des système de syndication RSS les plus intéressants que j'aie vus, c'est celui utilisé par fudforum. C'est avant tout axé vers l'extraction du contenu d'un forum pour l'afficher dans un site web "compagnon" mais ça pourrait donner des idées pour la notification. Si ma mémoire est bonne, l'url du flux lui-même permet le passage de paramètres : rss.php?userid=...&type=lastposts&... (etc)

On pourrait sans doute s'en servir pour passer les éléments d'autorisation ou de type de cette façon.

Si ce que je raconte est trivial, merci de ne pas en tenir compte ;)

plg · 2005-08-07 18:52:01

Depuis quelques semaines, je pense que l'approche par fréquence fixe est mauvaise. C'est difficile à gérer proprement et le problème que je soulève (dans le second post de ce topic) n'a pas de vraie solution. Je propose une approche un peu différente pour se concentrer sur les flux à fréquence de relevé variable : possibilité d'avoir autant de flux que souhaités par utilisateur.

Au niveau de la base, c'est simple : on déplace users.feed_id et users.last_feed_check dans la nouvelle table "feeds" (id, user_id, last_check). Ceci nous permet d'avoir N flux pour chaque utilisateur... notamment pour l'invité non connecté (2 par défaut).

Il reste un (gros ?) problème d'ordre ergonomique : le lien vers le flux fait parti de la page category.php (menu "Sommaire") et l'URL contient un identifiant de flux. Or, il me semble totalement exclu de recréer un nouvel identifiant à chaque rafraîchissement de la page (avec l'insertion dans la table des flux en même temps). Il faudrait donc une page intermédiaire qui donnerait une nouvelle URL de flux pour l'utilisateur connecté. On cliquerait sur "flux de notification", une page se charge et créé un nouveau flux et affiche le lien vers le flux.

C'est moche, non ? Que pensez-vous de l'abandon du relevé à fréquence fixe ? Avez-vous une suggestion ergonomique pour le "multiflux" ?

plg · 2005-09-08 22:50:55

Pas de réponse et pourtant c'est une fonctionnalité clef de la branche 1.5. En effet, il ne s'agit pas d'une amélioration, mais de quelque chose de complètement nouveau et pourtant indispensable depuis longtemps...

Les devs pour la branche 1.5 sont terminés, je règle les derniers détails avant la 1.5.0RC1 et j'ai statué tout seul :-/ d'abandonner le flux à fréquence fixe comme décrit dans mon précédent message. Le problème ergonomique n'est en pas vraiment un : une simple page présente un lien vers un flux dont l'URL est générée dynamiquement pour contenir un identifiant de flux unique et personnel.

La nouvelle page de maintenance [Administration > Général > Maintenance] permet de supprimer les flux inutilisés.

Piwigo.org

Annonce

#1 2005-06-23 00:07:41

[discussion] branche 1.5, notification

#2 2005-06-23 00:10:03

Re: [discussion] branche 1.5, notification

#3 2005-07-06 23:07:50

Re: [discussion] branche 1.5, notification

#4 2005-07-16 17:40:25

Re: [discussion] branche 1.5, notification

#5 2005-07-17 01:18:02

Re: [discussion] branche 1.5, notification

z0rglub a écrit:

#6 2005-07-17 10:52:45

Re: [discussion] branche 1.5, notification

timo a écrit:

specifications a écrit:

timo a écrit:

timo a écrit:

timo a écrit:

#7 2005-07-17 11:58:33

Re: [discussion] branche 1.5, notification

#8 2005-07-17 12:40:54

Re: [discussion] branche 1.5, notification

timo a écrit:

#9 2005-07-17 14:49:07

Re: [discussion] branche 1.5, notification

#10 2005-07-17 15:11:57

Re: [discussion] branche 1.5, notification

#11 2005-08-01 19:30:31

Re: [discussion] branche 1.5, notification

z0rglub a écrit:

#12 2005-08-07 18:52:01

Re: [discussion] branche 1.5, notification

#13 2005-09-08 22:50:55

Re: [discussion] branche 1.5, notification

Pied de page des forums