Ayant basculé sur Alphanet depuis un moment, j'ai décidé de relever
les news de free où j'étais abonné à plus de groupes fr.*
Et là bizarre : pas de nouveaux messages depuis 3 mois et 21 jours.
Je rajoute ces groupes au profil Alphanet et idem, il relève des
messages, mais aucun nouveau depuis cette date chez Alphanet !
Tous les groupes dont j'ai cessé la relève chez Free, et que je
reprends à nouveau sont bloqués dans le passé, quelque soit le serveur.
Test avec fr.soc.economie sur les deux serveurs : relève de messages
(200 sur Alpha, 5000 sur Free) et ligne vide dans la fenêtre de
chaque serveur : Non lus = Total = vide.
J'ai demandé à 4D une vérification, tout est impeccable. Une idée de
ce que je dois faire ?
Merci,
MacCafé 1.10
--
Vie : n. f. Maladie mortelle sexuellement transmissible
benoit chez leraillez.com
Quelque chose comme un process par groupe* et stockage dans un fichier/dossier temp et un process qui ajoute ces données à la base. Mais bon, ça c'est sur le papier, après il faut vouloir le faire et voir si c'est vraiment utile de compliquer la bête.
Il faut aller plus loin sur le papier, et penser à la gestion des données pour le cas le ton application. Je te laisse juste le soin de réfléchir à la gestion du téléchargement quasi simultané du même message crossposté sur plusieurs groupes. La condition de base étant que tu ne dois avoir qu'un seul message avec le même MID dans la base… Très certainement faisable, mais le jeu en vaut-il la chandelle ?
P.S. Le fait de pouvoir télécharger plusieurs messages simultanément n'a pas grand intérêt quand on a : 1. De la bande passante.
Moi j'aurai dit l'inverse ;-) Si tu n'as pas de bande passante et que tu téléchargé 4 messages en même temps (parce que dans les RFC je n'ai vu (à moins de l'avoir loupée) aucune commande pour charger un "morceau" de message) en gros pour simplifier, quand tu lances la relève, tu attends 4 fois plus longtemps pour lire le premier message.
Quelque chose comme un process par groupe* et stockage dans un
fichier/dossier temp et un process qui ajoute ces données à la
base. Mais bon, ça c'est sur le papier, après il faut vouloir le
faire et voir si c'est vraiment utile de compliquer la bête.
Il faut aller plus loin sur le papier, et penser à la gestion des
données pour le cas le ton application.
Je te laisse juste le soin de réfléchir à la gestion du
téléchargement quasi simultané du même message crossposté sur
plusieurs groupes.
La condition de base étant que tu ne dois avoir qu'un seul message
avec le même MID dans la base…
Très certainement faisable, mais le jeu en vaut-il la chandelle ?
P.S. Le fait de pouvoir télécharger plusieurs messages simultanément
n'a pas grand intérêt quand on a :
1. De la bande passante.
Moi j'aurai dit l'inverse ;-)
Si tu n'as pas de bande passante et que tu téléchargé 4 messages en
même temps (parce que dans les RFC je n'ai vu (à moins de l'avoir
loupée) aucune commande pour charger un "morceau" de message) en gros
pour simplifier, quand tu lances la relève, tu attends 4 fois plus
longtemps pour lire le premier message.
Quelque chose comme un process par groupe* et stockage dans un fichier/dossier temp et un process qui ajoute ces données à la base. Mais bon, ça c'est sur le papier, après il faut vouloir le faire et voir si c'est vraiment utile de compliquer la bête.
Il faut aller plus loin sur le papier, et penser à la gestion des données pour le cas le ton application. Je te laisse juste le soin de réfléchir à la gestion du téléchargement quasi simultané du même message crossposté sur plusieurs groupes. La condition de base étant que tu ne dois avoir qu'un seul message avec le même MID dans la base… Très certainement faisable, mais le jeu en vaut-il la chandelle ?
P.S. Le fait de pouvoir télécharger plusieurs messages simultanément n'a pas grand intérêt quand on a : 1. De la bande passante.
Moi j'aurai dit l'inverse ;-) Si tu n'as pas de bande passante et que tu téléchargé 4 messages en même temps (parce que dans les RFC je n'ai vu (à moins de l'avoir loupée) aucune commande pour charger un "morceau" de message) en gros pour simplifier, quand tu lances la relève, tu attends 4 fois plus longtemps pour lire le premier message.
Le 1er octobre 2020 à 08:07, Gilbert OLIVIER se permit de dire :
Le 30 septembre 2020 à 22:56, Benoit a écrit :
Quelque chose comme un process par groupe* et stockage dans un fichier/dossier temp et un process qui ajoute ces données à la base. Mais bon, ça c'est sur le papier, après il faut vouloir le faire et voir si c'est vraiment utile de compliquer la bête.
Il faut aller plus loin sur le papier, et penser à la gestion des données pour le cas le ton application. Je te laisse juste le soin de réfléchir à la gestion du téléchargement quasi simultané du même message crossposté sur plusieurs groupes.
C'est pourtant simple : de la même façon que tu le fais aujourd'hui. Tu ne changes rien. Tu as un seul process pour ajouter des messages à la base : tu continues de même. La différence est qu'au lieu de gérer les messages à leur arrivée, tu le fais lors de la lecture d'un fichier temp sur le disque (ou en ram) et l'ajout d'un message à la base. Pour info, tu n'as besoin de conserver que la liste des messages reçus lors de la relève en cours pour la très grande majorité des cas et vérifier après coup, au cas où il ait déjà été reçu. Ce sujet me fait penser au fait que tu ne marques pas un message déjà lu dans un autre groupe : sauf si c'est un que tu as envoyé, lui tu sais le marqué comme lu ! Ce qui est certes très facile puisqu'il n'y a que le « From » a détecter à la réception. ;) Si un message est crossposté, tu le sais, c'est dans les headers, il est donc « facile » de savoir flagué un message à plusieurs endroits quand il est lu une première fois. Tu peux même le flaguer à l'avance en donnant son MID à une liste d'attente dans un groupe pas encore relevé. Un point à voir : que faire lorsqu'on relève pour la première fois un groupe et qu'il contient des messages déjà lus, il y a un bail. (Àmha, là on peut le laisser non lus puisqu'il va apparaitre dans une enfilade et je ne suis pas sur que ce soit agréable de prendre une enfilade depuis le début et sauter des messages)
La condition de base étant que tu ne dois avoir qu'un seul message avec le même MID dans la base…
Non, voir ce-dessus. Si tu as plusieurs messages avec le même MID, à la lecture du premier tu le sais et tu sais où les autres se trouvent puisque tu as la liste des groupes dans les headers.
Très certainement faisable, mais le jeu en vaut-il la chandelle ?
C'est un petit truc pour le confort lors de la lecture des messages.
P.S. Le fait de pouvoir télécharger plusieurs messages simultanément n'a pas grand intérêt quand on a : 1. De la bande passante.
Moi j'aurai dit l'inverse ;-)
Oops ! Je devrais réfléchir plus vite que je n'écris. Quoique (cf. plus bas)
Si tu n'as pas de bande passante et que tu téléchargé 4 messages en même temps (parce que dans les RFC je n'ai vu (à moins de l'avoir loupée) aucune commande pour charger un "morceau" de message) en gros pour simplifier, quand tu lances la relève, tu attends 4 fois plus longtemps pour lire le premier message.
1. Cela veut dire que : - Tu ne les reçois pas dans l'ordre ; - Tu ne saches pas les afficher au fil de l'eau dans la fenêtre du groupe (mise à jour de la liste des non-lus par exemple). Mais uniquement si la fenêtre du groupe n'est pas au premier plan ; sinon : bonjour pour cliquer sur le bon message quand la liste change. 2. Tout dépend en fait de ta vitesse de lecture d'un message, et d'une éventuelle rédaction de réponse, par rapport au temps de téléchargement des suivants. 3. Et puis tu peux n'afficher que les messages des groupes entièrement chargés. À ce propos, tu peux très bien ne pas charger plusieurs messages d'un même groupe mais un message par groupe, dans plusieurs groupes. Ce qui fait que lorsque tu as un gros groupe en téléchargement, les autres peuvent être lus sans problème. Rien que ça serait cool avec Free ;) -- Vie : n. f. Maladie mortelle sexuellement transmissible benoit chez leraillez.com
Le 1er octobre 2020 à 08:07, Gilbert OLIVIER se permit de dire :
Le 30 septembre 2020 à 22:56, Benoit a écrit :
Quelque chose comme un process par groupe* et stockage dans un
fichier/dossier temp et un process qui ajoute ces données à la
base. Mais bon, ça c'est sur le papier, après il faut vouloir le
faire et voir si c'est vraiment utile de compliquer la bête.
Il faut aller plus loin sur le papier, et penser à la gestion des
données pour le cas le ton application.
Je te laisse juste le soin de réfléchir à la gestion du
téléchargement quasi simultané du même message crossposté sur
plusieurs groupes.
C'est pourtant simple : de la même façon que tu le fais aujourd'hui.
Tu ne changes rien. Tu as un seul process pour ajouter des messages à
la base : tu continues de même. La différence est qu'au lieu de gérer
les messages à leur arrivée, tu le fais lors de la lecture d'un
fichier temp sur le disque (ou en ram) et l'ajout d'un message à la
base.
Pour info, tu n'as besoin de conserver que la liste des messages
reçus lors de la relève en cours pour la très grande majorité des cas
et vérifier après coup, au cas où il ait déjà été reçu.
Ce sujet me fait penser au fait que tu ne marques pas un message déjà
lu dans un autre groupe : sauf si c'est un que tu as envoyé, lui tu
sais le marqué comme lu ! Ce qui est certes très facile puisqu'il n'y
a que le « From » a détecter à la réception. ;)
Si un message est crossposté, tu le sais, c'est dans les headers, il
est donc « facile » de savoir flagué un message à plusieurs endroits
quand il est lu une première fois. Tu peux même le flaguer à l'avance
en donnant son MID à une liste d'attente dans un groupe pas encore
relevé. Un point à voir : que faire lorsqu'on relève pour la première
fois un groupe et qu'il contient des messages déjà lus, il y a un
bail. (Àmha, là on peut le laisser non lus puisqu'il va apparaitre
dans une enfilade et je ne suis pas sur que ce soit agréable de
prendre une enfilade depuis le début et sauter des messages)
La condition de base étant que tu ne dois avoir qu'un seul message
avec le même MID dans la base…
Non, voir ce-dessus. Si tu as plusieurs messages avec le même MID, à
la lecture du premier tu le sais et tu sais où les autres se trouvent
puisque tu as la liste des groupes dans les headers.
Très certainement faisable, mais le jeu en vaut-il la chandelle ?
C'est un petit truc pour le confort lors de la lecture des messages.
P.S. Le fait de pouvoir télécharger plusieurs messages simultanément
n'a pas grand intérêt quand on a :
1. De la bande passante.
Moi j'aurai dit l'inverse ;-)
Oops ! Je devrais réfléchir plus vite que je n'écris. Quoique (cf.
plus bas)
Si tu n'as pas de bande passante et que tu téléchargé 4 messages en
même temps (parce que dans les RFC je n'ai vu (à moins de l'avoir
loupée) aucune commande pour charger un "morceau" de message) en gros
pour simplifier, quand tu lances la relève, tu attends 4 fois plus
longtemps pour lire le premier message.
1. Cela veut dire que :
- Tu ne les reçois pas dans l'ordre ;
- Tu ne saches pas les afficher au fil de l'eau dans la fenêtre
du groupe (mise à jour de la liste des non-lus par exemple).
Mais uniquement si la fenêtre du groupe n'est pas au premier plan ;
sinon : bonjour pour cliquer sur le bon message quand la liste
change.
2. Tout dépend en fait de ta vitesse de lecture d'un message, et
d'une éventuelle rédaction de réponse, par rapport au temps de
téléchargement des suivants.
3. Et puis tu peux n'afficher que les messages des groupes
entièrement chargés. À ce propos, tu peux très bien ne pas charger
plusieurs messages d'un même groupe mais un message par groupe, dans
plusieurs groupes. Ce qui fait que lorsque tu as un gros groupe en
téléchargement, les autres peuvent être lus sans problème. Rien que
ça serait cool avec Free ;)
--
Vie : n. f. Maladie mortelle sexuellement transmissible
benoit chez leraillez.com
Le 1er octobre 2020 à 08:07, Gilbert OLIVIER se permit de dire :
Le 30 septembre 2020 à 22:56, Benoit a écrit :
Quelque chose comme un process par groupe* et stockage dans un fichier/dossier temp et un process qui ajoute ces données à la base. Mais bon, ça c'est sur le papier, après il faut vouloir le faire et voir si c'est vraiment utile de compliquer la bête.
Il faut aller plus loin sur le papier, et penser à la gestion des données pour le cas le ton application. Je te laisse juste le soin de réfléchir à la gestion du téléchargement quasi simultané du même message crossposté sur plusieurs groupes.
C'est pourtant simple : de la même façon que tu le fais aujourd'hui. Tu ne changes rien. Tu as un seul process pour ajouter des messages à la base : tu continues de même. La différence est qu'au lieu de gérer les messages à leur arrivée, tu le fais lors de la lecture d'un fichier temp sur le disque (ou en ram) et l'ajout d'un message à la base. Pour info, tu n'as besoin de conserver que la liste des messages reçus lors de la relève en cours pour la très grande majorité des cas et vérifier après coup, au cas où il ait déjà été reçu. Ce sujet me fait penser au fait que tu ne marques pas un message déjà lu dans un autre groupe : sauf si c'est un que tu as envoyé, lui tu sais le marqué comme lu ! Ce qui est certes très facile puisqu'il n'y a que le « From » a détecter à la réception. ;) Si un message est crossposté, tu le sais, c'est dans les headers, il est donc « facile » de savoir flagué un message à plusieurs endroits quand il est lu une première fois. Tu peux même le flaguer à l'avance en donnant son MID à une liste d'attente dans un groupe pas encore relevé. Un point à voir : que faire lorsqu'on relève pour la première fois un groupe et qu'il contient des messages déjà lus, il y a un bail. (Àmha, là on peut le laisser non lus puisqu'il va apparaitre dans une enfilade et je ne suis pas sur que ce soit agréable de prendre une enfilade depuis le début et sauter des messages)
La condition de base étant que tu ne dois avoir qu'un seul message avec le même MID dans la base…
Non, voir ce-dessus. Si tu as plusieurs messages avec le même MID, à la lecture du premier tu le sais et tu sais où les autres se trouvent puisque tu as la liste des groupes dans les headers.
Très certainement faisable, mais le jeu en vaut-il la chandelle ?
C'est un petit truc pour le confort lors de la lecture des messages.
P.S. Le fait de pouvoir télécharger plusieurs messages simultanément n'a pas grand intérêt quand on a : 1. De la bande passante.
Moi j'aurai dit l'inverse ;-)
Oops ! Je devrais réfléchir plus vite que je n'écris. Quoique (cf. plus bas)
Si tu n'as pas de bande passante et que tu téléchargé 4 messages en même temps (parce que dans les RFC je n'ai vu (à moins de l'avoir loupée) aucune commande pour charger un "morceau" de message) en gros pour simplifier, quand tu lances la relève, tu attends 4 fois plus longtemps pour lire le premier message.
1. Cela veut dire que : - Tu ne les reçois pas dans l'ordre ; - Tu ne saches pas les afficher au fil de l'eau dans la fenêtre du groupe (mise à jour de la liste des non-lus par exemple). Mais uniquement si la fenêtre du groupe n'est pas au premier plan ; sinon : bonjour pour cliquer sur le bon message quand la liste change. 2. Tout dépend en fait de ta vitesse de lecture d'un message, et d'une éventuelle rédaction de réponse, par rapport au temps de téléchargement des suivants. 3. Et puis tu peux n'afficher que les messages des groupes entièrement chargés. À ce propos, tu peux très bien ne pas charger plusieurs messages d'un même groupe mais un message par groupe, dans plusieurs groupes. Ce qui fait que lorsque tu as un gros groupe en téléchargement, les autres peuvent être lus sans problème. Rien que ça serait cool avec Free ;) -- Vie : n. f. Maladie mortelle sexuellement transmissible benoit chez leraillez.com
Benoit
Le 30 septembre 2020 à 23:46, M.V. d'un élan de joie s'exprima ainsi :
C'est à 22 h 56 le 30 septembre 2020 que le dénommé Benoit a écrit ces lignes :
Il me semble avoir vu passer une 2.0b
Pas possible. On en est à la 2.0b5 et ça a commencé par 2.0b1 : il n'y a jamais eu de 2.0b.
Sache que si le b m'a marqué l'esprit, le nombre qui se trouve derrière je m'en carre comme tu ne peux l'imaginer. Le jour où j'aurai besoin de mémoriser ce détail ne s'est pas encore levé.
De plus, les versions beta ne sont pas publiques. Tu as rêvé.
C'est pas publique ça : User-Agent: MacCafe/2.0b5 (macOS 10.14.6 (18G6032) - MacBookAir7,2) -- Vie : n. f. Maladie mortelle sexuellement transmissible benoit chez leraillez.com
Le 30 septembre 2020 à 23:46, M.V. d'un élan de joie s'exprima ainsi :
C'est à 22 h 56 le 30 septembre 2020 que le dénommé Benoit a écrit ces
lignes :
Il me semble avoir vu passer une 2.0b
Pas possible. On en est à la 2.0b5 et ça a commencé par 2.0b1 : il n'y
a jamais eu de 2.0b.
Sache que si le b m'a marqué l'esprit, le nombre qui se trouve
derrière je m'en carre comme tu ne peux l'imaginer. Le jour où
j'aurai besoin de mémoriser ce détail ne s'est pas encore levé.
De plus, les versions beta ne sont pas publiques.
Tu as rêvé.
C'est pas publique ça :
User-Agent: MacCafe/2.0b5 (macOS 10.14.6 (18G6032) - MacBookAir7,2)
--
Vie : n. f. Maladie mortelle sexuellement transmissible
benoit chez leraillez.com
Le 30 septembre 2020 à 23:46, M.V. d'un élan de joie s'exprima ainsi :
C'est à 22 h 56 le 30 septembre 2020 que le dénommé Benoit a écrit ces lignes :
Il me semble avoir vu passer une 2.0b
Pas possible. On en est à la 2.0b5 et ça a commencé par 2.0b1 : il n'y a jamais eu de 2.0b.
Sache que si le b m'a marqué l'esprit, le nombre qui se trouve derrière je m'en carre comme tu ne peux l'imaginer. Le jour où j'aurai besoin de mémoriser ce détail ne s'est pas encore levé.
De plus, les versions beta ne sont pas publiques. Tu as rêvé.
C'est pas publique ça : User-Agent: MacCafe/2.0b5 (macOS 10.14.6 (18G6032) - MacBookAir7,2) -- Vie : n. f. Maladie mortelle sexuellement transmissible benoit chez leraillez.com
M.V.
Le 1er octobre 2020 à 16 h 30, Benoit s'est exprimé en ces termes :
Ce sujet me fait penser au fait que tu ne marques pas un message déjà lu dans un autre groupe
Gilbert l'a dit plusieurs fois ici-même : c'était volontaire, un choix de sa part et comme c'est notre "chef"… Cependant, il semble, dans nos discussions du "groupe des 4", que Gilbert ait récemment changé d'avis et que la prochaine version officielle en tiendra compte. -- Michel VAUQUOIS - <http://michelvauquois.fr>
Le 1er octobre 2020 à 16 h 30, Benoit s'est exprimé en ces termes :
Ce sujet me fait penser au fait que tu ne marques pas un message déjà
lu dans un autre groupe
Gilbert l'a dit plusieurs fois ici-même : c'était volontaire, un choix
de sa part et comme c'est notre "chef"…
Cependant, il semble, dans nos discussions du "groupe des 4", que
Gilbert ait récemment changé d'avis et que la prochaine version
officielle en tiendra compte.
--
Michel VAUQUOIS - <http://michelvauquois.fr>
Le 1er octobre 2020 à 16 h 30, Benoit s'est exprimé en ces termes :
Ce sujet me fait penser au fait que tu ne marques pas un message déjà lu dans un autre groupe
Gilbert l'a dit plusieurs fois ici-même : c'était volontaire, un choix de sa part et comme c'est notre "chef"… Cependant, il semble, dans nos discussions du "groupe des 4", que Gilbert ait récemment changé d'avis et que la prochaine version officielle en tiendra compte. -- Michel VAUQUOIS - <http://michelvauquois.fr>
M.V.
Ainsi parlait Benoit le 1er octobre 2020 à 16 h 30 :
De plus, les versions beta ne sont pas publiques. Tu as rêvé.
C'est pas publique ça : User-Agent: MacCafe/2.0b5 (macOS 10.14.6 (18G6032) - MacBookAir7,2)
??? C'est ça que tu appelles "avoir vu passer" ? Nous sommes 4 à disposer de la dernière beta 2.0b5 et personne d'autre. Je te le redis : les versions beta de MacCafé ne sont pas publiquement disponibles. -- Michel VAUQUOIS - <http://michelvauquois.fr>
Ainsi parlait Benoit le 1er octobre 2020 à 16 h 30 :
De plus, les versions beta ne sont pas publiques.
Tu as rêvé.
C'est pas publique ça :
User-Agent: MacCafe/2.0b5 (macOS 10.14.6 (18G6032) - MacBookAir7,2)
???
C'est ça que tu appelles "avoir vu passer" ?
Nous sommes 4 à disposer de la dernière beta 2.0b5 et personne d'autre.
Je te le redis : les versions beta de MacCafé ne sont pas publiquement
disponibles.
--
Michel VAUQUOIS - <http://michelvauquois.fr>
Ainsi parlait Benoit le 1er octobre 2020 à 16 h 30 :
De plus, les versions beta ne sont pas publiques. Tu as rêvé.
C'est pas publique ça : User-Agent: MacCafe/2.0b5 (macOS 10.14.6 (18G6032) - MacBookAir7,2)
??? C'est ça que tu appelles "avoir vu passer" ? Nous sommes 4 à disposer de la dernière beta 2.0b5 et personne d'autre. Je te le redis : les versions beta de MacCafé ne sont pas publiquement disponibles. -- Michel VAUQUOIS - <http://michelvauquois.fr>
