Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > it.tlc.cellulari.android > #111569
| Subject | [1.3.2] - Per soddisfare le ultime richieste... |
|---|---|
| From | MCSM <despammed@mcsm.anonaddy.me> |
| Newsgroups | it.tlc.cellulari.android |
| Message-ID | <mn.4bd97ea9b7453ab8.0@mcsm.org> (permalink) |
| Organization | mcsm.org |
| Date | 2026-09-09 16:25 +0200 |
DL diretto:
https://sourceforge.net/projects/nereo/files/1.3.2/NeReO_1.3.2.apk/download
Pagina su SF:
https://sourceforge.net/projects/nereo/
dovrei aver accontentato quasi tutti (pure BIG Umberto)...
*** VERSIONE 1.3.2 ***
Novità di questa versione:
* Anche sul TELEFONO si può andare dritti al primo messaggio non
letto. Nuova opzione facoltativa in Aspetto -> "Tocca la
discussione per aprire il primo non letto": toccando la testa di
una discussione si apre il primo messaggio non ancora letto,
invece del primo post (se sono gia' tutti letti, si apre il primo
post). Vale nella vista AD ALBERO e in quella RAGGRUPPATA.
* Spenta di default: chi non la accende non nota alcuna differenza.
Nella vista raggruppata, se e' accesa anche "Tocca il messaggio
per espandere il thread", ESPANDERE HA LA PRECEDENZA - lì il
thread si apre sul posto e restare nella lista e' la cosa sensata.
* Perche' un'opzione nuova e non la stessa della 1.3.1: quella
agisce solo dove una riga rappresenta l'intera discussione
richiudibile (vista raggruppata), e nella vista ad albero -
proprio quella per cui la funzione e' stata chiesta - quel
presupposto non esiste. Riusare l'interruttore esistente non
avrebbe potuto funzionare: sono due comportamenti diversi in due
viste diverse, quindi due interruttori.
* User-Agent nella forma prevista dalla RFC 5536 (nota tecnica di
Dave
Royal): ora NeReO/1.3.2 (Android), con la versione attaccata da una
BARRA. Fino alla 1.3.1 era "NeReO 1.3.1 (Android)", con uno spazio.
* Perche' non era solo estetica: la RFC 5536 par. 3.2.13 definisce
product = [CFWS] token [ [CFWS] "/" product-version ], cioe' la
versione si attacca al prodotto con la barra. Con lo spazio
l'intestazione non era ILLEGALE - la grammatica ammette piu'
prodotti e "1.3.1" e' un token valido - ma diceva un'altra cosa:
DUE PRODOTTI, uno di nome "NeReO" e uno di nome "1.3.1". Chi
raccoglie statistiche sui newsreader leggeva un software
inesistente. Il commento "(Android)" e' CFWS ed era gia' corretto.
* Le identità gia' salvate vengono riallineate una volta sola, e
SOLO se contengono ancora esattamente uno dei predefiniti spediti
da noi. Uno User-Agent scritto dall'utente non viene mai toccato -
campo vuoto compreso, che dalla 1.2.9 significa "non dichiarare
nulla" ed e' una scelta, non una dimenticanza.
* Corretto: se l'ultimo articolo di un gruppo veniva cancellato,
quel gruppo non si aggiornava piu'. Ogni tentativo rispondeva
"423 No articles in NNNN-NNNN" e si sbloccava da solo soltanto
quando qualcuno postava di nuovo.
* Perche' succedeva: cancellato l'ultimo articolo, il numero alto
dichiarato dal gruppo NON scende (RFC 3977 par. 6.1.1: non tutti i
numeri fra il water mark basso e quello alto corrispondono a
articoli esistenti), quindi NeReO chiedeva l'intervallo dal
proprio segnalibro fino a quel numero - ormai vuoto. Il 423 che il
server restituisce NON e' un errore: la RFC 3977 par. 8.3 lo
definisce "nessun articolo in quell'intervallo", ed e' la risposta
giusta. NeReO lo trattava come fatale.
* Cosa costava davvero, oltre all'errore a schermo: la connessione
condivisa veniva buttata e riaperta per i gruppi rimanenti (socket
+ TLS + autenticazione da capo, a ogni aggiornamento), il gruppo
veniva saltato dalla guardia anti-loop, e il segnalibro non
avanzava mai - quindi l'aggiornamento dopo richiedeva lo stesso
intervallo morto. Ora il 423 produce una lista vuota, il
segnalibro avanza e l'intervallo morto si consuma una volta sola.
* Non era un caso di laboratorio: il buco fra numero basso e numero
alto e' previsto dal protocollo, e i cancel di spam sull'ultimo
articolo di un gruppo poco trafficato sono ordinaria
amministrazione. Il test deliberato di BIG Umberto su alt.test.a,
riprodotto tre volte su tre server diversi (Solani,
eternal-september, Paganini), non ha inventato uno scenario
impossibile: ha reso riproducibile una cosa che capita da sola e
che finora poteva essere archiviata come "errore di connessione".
* Sotto il cofano: prima di aggiungere il QUINTO punto del codice
che calcola "primo non letto della discussione", la logica e'
stata estratta una volta sola e i cinque punti ora la
condividono. La 1.3 e' uscita con un difetto proprio perche' una
correzione era stata applicata a due copie su quattro di un
blocco duplicato.
--
.:. MCSM .:.
-> posting from PC with MesNews <-
Back to it.tlc.cellulari.android | Previous | Next — Next in thread | Find similar | Unroll thread
[1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-09 16:25 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... Roxy <roxy@hotmail.com> - 2026-09-09 17:48 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-09 17:43 +0000
[LUNGO] Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-10 08:51 +0200
Re: [LUNGO] Re: [1.3.2] - Per soddisfare le ultime richieste... Macchia <TOGLIMI_la.macchia.nera@gmail.com> - 2026-09-10 07:15 +0000
Re: [LUNGO] Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-10 09:46 +0200
Re: [LUNGO] Re: [1.3.2] - Per soddisfare le ultime richieste... Roxy <roxy@hotmail.com> - 2026-09-10 09:30 +0200
Re: [LUNGO] Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-10 10:08 +0200
Re: [LUNGO] Re: [1.3.2] - Per soddisfare le ultime richieste... Roxy <roxy@hotmail.com> - 2026-09-10 10:13 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-10 11:21 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... Roxy <roxy@hotmail.com> - 2026-09-10 11:42 +0200
[LUNGO] Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-10 12:13 +0200
Re: [LUNGO] Re: [1.3.2] - Per soddisfare le ultime richieste... Roxy <roxy@hotmail.com> - 2026-09-10 13:55 +0000
Re: [1.3.2] - Per soddisfare le ultime richieste... SiMcarD <simcard@despammed.com> - 2026-09-09 18:26 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... Bingo3331 <invalid@invalid.com> - 2026-09-09 16:43 +0000
Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-09 17:45 +0000
Re: [1.3.2] - Per soddisfare le ultime richieste... fandango <fandango@invalid.invalid> - 2026-09-10 08:47 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-10 09:05 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... Jk <jk@people.it> - 2026-09-10 09:41 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-10 09:56 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... Bingo3331 <invalid@invalid.com> - 2026-09-10 09:30 +0000
Re: [1.3.2] - Per soddisfare le ultime richieste... fandango <fandango@invalid.invalid> - 2026-09-10 13:34 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... SiMcarD <simcard@despammed.com> - 2026-09-10 17:39 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-10 18:58 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... Bingo3331 <invalid@invalid.com> - 2026-09-10 09:37 +0000
Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-10 12:16 +0200
Re: [1.3.2] - Per soddisfare le ultime richieste... Cercaparole <cercaparole@-.dai> - 2026-09-11 12:22 +0000
Re: [1.3.2] - Per soddisfare le ultime richieste... MCSM <despammed@mcsm.anonaddy.me> - 2026-09-11 15:58 +0200
csiph-web