[flnews] Option "nntp_no_over"

[Marcel Logen]

Die Option "nntp_no_over" ist in der flnews-man-page beschrieben.

Mir ist aufgefallen, daß in dem Fall, daß sie auf "1" steht,
das Verzeichnis "headers" befüllt wird.

individual scheint kein OVER zu kennen, da ist es flnews wohl
egal, ob die Option auf "0" oder non-zero steht: Es wird immer
das Verzeichnis "headers" benutzt.

Ist meine Beobachtung korrekt, oder habe ich etwas übersehen?

Mein Vorschlag zur Ergänzung der man page (bei "nntp_no_over"):

- Hinweis auf Verzeichnis "headers" (als "local cache")

- Hinweis darauf, daß "headers" immer benutzt wird, wenn der
Server kein OVER kann, unabhängig vom Wert von "nntp_no_over"

Ich habe gesehen, daß unter FILES das Verzeichnis "headers/*"
erwähnt ist, fände es aber sinnvoll, das auch bei "nntp_no_over"
zu erwähnen oder dort zumindest auf FILES hinzuweisen.

Marcel q6nk (858868)

PS: Zu -confprefix: Hier fände ich den Hinweis sinnvoll, daß
der entsprechende "path" ohne abschließenden Backslash an-
zugeben ist.

[supersedes]

[Stefan Wiens]

Post by Marcel Logen
Die Option "nntp_no_over" ist in der flnews-man-page beschrieben.
Mir ist aufgefallen, daß in dem Fall, daß sie auf "1" steht,
das Verzeichnis "headers" befüllt wird.
individual scheint kein OVER zu kennen,

,----
| group de.test
| 211 9413 644646 654363 de.test
| over
| 500 What?
`----

Post by Marcel Logen
Es wird immer das Verzeichnis "headers" benutzt.
Ist meine Beobachtung korrekt, oder habe ich etwas übersehen?
- Hinweis auf Verzeichnis "headers" (als "local cache")
- Hinweis darauf, daß "headers" immer benutzt wird, wenn der
Server kein OVER kann, unabhängig vom Wert von "nntp_no_over"
Ich habe gesehen, daß unter FILES das Verzeichnis "headers/*"
erwähnt ist, fände es aber sinnvoll, das auch bei "nntp_no_over"
zu erwähnen oder dort zumindest auf FILES hinzuweisen.
Marcel q6nk (858868)
PS: Zu -confprefix: Hier fände ich den Hinweis sinnvoll, daß
der entsprechende "path" ohne abschließenden Backslash an-
zugeben ist.
[supersedes]

[Marcel Logen]

Post by Stefan Wiens

Post by Marcel Logen
individual scheint kein OVER zu kennen,

,----
| group de.test
| 211 9413 644646 654363 de.test
| over
| 500 What?
`----

Ich hatte es mit "CAPABILITIES" und "HELP" versucht:
Kein Hinweis auf OVER.

Marcel qa8n (862487)

[Michael Bäuerle]

Post by Marcel Logen
Die Option "nntp_no_over" ist in der flnews-man-page beschrieben.
Mir ist aufgefallen, daß in dem Fall, daß sie auf "1" steht,
das Verzeichnis "headers" befüllt wird.
individual scheint kein OVER zu kennen, da ist es flnews wohl
egal, ob die Option auf "0" oder non-zero steht: Es wird immer
das Verzeichnis "headers" benutzt.
Ist meine Beobachtung korrekt, oder habe ich etwas übersehen?

Nein, genau so funktioniert es.

flnews verwendet den Overview nur, wenn der Server die Capability
OVER anbietet:
<https://datatracker.ietf.org/doc/html/rfc3977#section-3.3.2>
Wenn flnews mit "-debug" gestartet wurde, sollte das im logfile
für Individual aber so aussehen:
|
| [=>] CAPABILITIES
| [<=] 500 What?
| [Switch to NNTP V1 (RFC 977) mode]

Es wird dann das alte NNTP-Protokoll gemäß RFC 977 verwendet.
Die Erweiterungen dafür gemäß RFC 2980 (z.B. XOVER) werden nicht
unterstützt.

Die Option "nntp_no_over" schaltet die Verwendung des Overview
ab, wenn er verfügbar wäre. Ansonsten hat sie keinen Effekt, wie
im Beispiel oben.

flnews unterstützt den NNTP Pipeline-Modus nicht:
<https://datatracker.ietf.org/doc/html/rfc3977#section-3.5>
und der Transfer vieler Header ist daher langsam (insbesondere
bei hoher Netzwerk-Latenz).
Das Verzeichnis "headers" dient als Cache. Wird eine neue Gruppe
betreten, dann geht das viel schneller, wenn die Mehrzahl der
Header aus diesem Cache geladen werden kann.

[Thomas Barghahn]

Post by Michael Bäuerle

[...]
individual scheint kein OVER zu kennen, [...]

flnews verwendet den Overview nur, wenn der Server die Capability
[...]
Es wird dann das alte NNTP-Protokoll gemäß RFC 977 verwendet.
Die Erweiterungen dafür gemäß RFC 2980 (z.B. XOVER) werden nicht
unterstützt.

Leider! :-( Bemerkbar macht sich dieses fehlende Feature schon, wenn man
bspw. einen *lokalen* Newsserver (siehe Hamster) verwendet, welche
ebenfalls kein "OVER" anbietet. In jenem Fall sind dann auch noch
schwankende Übertragungsraten per DSL (oder besser) vernachlässigbar.

Zudem hat niemand "XOVER" verboten!

Allein schon für /eine/ NewsGroup mit ca 100.000 Beiträgen braucht
flnews (nach dem Start) ca. *10* Sekunden, *um nur* den Artikelbaum
/dieser einen Gruppe/ zu aktualisieren. :-(
Wollt ihr ein Video sehen?

Aktuelle Newsreader, welche neben "OVER" auch "XOVER" verwenden und dann
/zusätzlich/ auch noch alle Artikel /samt Body(!)/ (siehe die Vielfalt
der noch vorhandenen Offline-Reader) laden, diese brauchen gerade einmal
einen Bruchteil dieser Zeit, um mehrere Gruppen gleicher Größe /samt
Abfrage von Mailkonten/ (POP3, IMAP) zu erledigen.

Nutzt man allerdings News-Server, welche "OVER" anbieten, so ist das
Arbeiten mit flnews durchaus angenehm. :-)

Thomas

[Michael Bäuerle]

Post by Marcel Logen
[...]
- Hinweis auf Verzeichnis "headers" (als "local cache")
- Hinweis darauf, daß "headers" immer benutzt wird, wenn der
Server kein OVER kann, unabhängig vom Wert von "nntp_no_over"
Ich habe gesehen, daß unter FILES das Verzeichnis "headers/*"
erwähnt ist, fände es aber sinnvoll, das auch bei "nntp_no_over"
zu erwähnen oder dort zumindest auf FILES hinzuweisen.

Hier ist eine geänderte man page enthalten:
<https://micha.freeshell.org/flnews/src/flnews-1.3.0pre2.tar.bz2>
Size(flnews-1.3.0pre2.tar.bz2)= 1266081
SHA2-256(flnews-1.3.0pre2.tar.bz2)= d1b7bc835e89b21fbe81f2c63c9625c43f1655ecde94a2b195dba36762255a2a

[Marcel Logen]

Vielen Dank für die entsprechenden Ergänzungen/Erläuterungen!

Marcel v3hf (1019439)

[Michael Bäuerle]

Post by Marcel Logen
[...]
PS: Zu -confprefix: Hier fände ich den Hinweis sinnvoll, daß
der entsprechende "path" ohne abschließenden Backslash an-
zugeben ist.

Das ist nicht der Fall. Ein abschließender Slash (nicht Backslash) ist
zulässig und funktioniert.

POSIX sagt dazu:
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271>
|
| A pathname can optionally contain one or more trailing <slash>
| characters. Multiple successive <slash> characters are considered
| to be the same as one <slash>, [...]

[Marcel Logen]

Post by Michael Bäuerle

Post by Marcel Logen
PS: Zu -confprefix: Hier fände ich den Hinweis sinnvoll, daß
der entsprechende "path" ohne abschließenden Backslash an-
zugeben ist.

Das ist nicht der Fall. Ein abschließender Slash (nicht Backslash) ist
zulässig und funktioniert.

Ich meinte natürlich auch den "Slash".

Post by Michael Bäuerle
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271>
|
| A pathname can optionally contain one or more trailing <slash>
| characters. Multiple successive <slash> characters are considered
| to be the same as one <slash>, [...]

Aufgefallen war mir, daß im Falle des trailing slash im -confprefix
folgendes im Terminal angezeigt wird, wenn man (ein mit -debug ge-
startetes) flnews beendet:

| flnews: CONF: Store to: /home/user20/.config/flne-individual//configfile

Das schadet aber dann wohl auch nicht.

Marcel ugga (999946)

[Michael Bäuerle]

Post by Marcel Logen

Post by Michael Bäuerle

Post by Marcel Logen
PS: Zu -confprefix: Hier fände ich den Hinweis sinnvoll, daß
der entsprechende "path" ohne abschließenden Backslash an-
zugeben ist.

Das ist nicht der Fall. Ein abschließender Slash (nicht Backslash) ist
zulässig und funktioniert.

Ich meinte natürlich auch den "Slash".

Post by Michael Bäuerle
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271>
|
| A pathname can optionally contain one or more trailing <slash>
| characters. Multiple successive <slash> characters are considered
| to be the same as one <slash>, [...]

Aufgefallen war mir, daß im Falle des trailing slash im -confprefix
folgendes im Terminal angezeigt wird, wenn man (ein mit -debug ge-
| flnews: CONF: Store to: /home/user20/.config/flne-individual//configfile
Das schadet aber dann wohl auch nicht.

Ich verstehe die POSIX-Norm so, dass das funktionieren muss (auch mit
mehr als zwei Slashes in der Mitte oder am Ende). Ich hatte diesen Teil
nicht komplett zitiert:
|
| Multiple successive <slash> characters are considered to be the same
| as one <slash>, except for the case of exactly two leading <slash>
| characters.

Mehrere Slashes werden demnach überall zusammengefasst, außer am Anfang.

Sollte es tatsächlich Systeme geben, die damit technisch ein Problem
haben, dann schaue ich nochmal danach.

[Peter J. Holzer]

Post by Michael Bäuerle
Ich verstehe die POSIX-Norm so, dass das funktionieren muss (auch mit
mehr als zwei Slashes in der Mitte oder am Ende).

ACK.

Post by Michael Bäuerle
|
| Multiple successive <slash> characters are considered to be the same
| as one <slash>, except for the case of exactly two leading <slash>
| characters.
Mehrere Slashes werden demnach überall zusammengefasst, außer am Anfang.

Zwei Slashes am Anfang markieren bei manchen Netzwerkfilesystemen den
Hostnamen. Heute den meisten vermutlich von Windows und URLs bekannt,
gab/gibt es aber auch bei Unix-Filesystemen (z.B. AFS, wenn ich mich
recht erinnere).

hp

[Marcel Logen]

Post by Michael Bäuerle

Post by Marcel Logen

Post by Michael Bäuerle

Post by Marcel Logen
PS: Zu -confprefix: Hier fände ich den Hinweis sinnvoll, daß
der entsprechende "path" ohne abschließenden Backslash an-
zugeben ist.

Das ist nicht der Fall. Ein abschließender Slash (nicht Backslash) ist
zulässig und funktioniert.

Ich meinte natürlich auch den "Slash".

Post by Michael Bäuerle
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271>
|
| A pathname can optionally contain one or more trailing <slash>
| characters. Multiple successive <slash> characters are considered
| to be the same as one <slash>, [...]

Aufgefallen war mir, daß im Falle des trailing slash im -confprefix
folgendes im Terminal angezeigt wird, wenn man (ein mit -debug ge-
| flnews: CONF: Store to: /home/user20/.config/flne-individual//configfile
Das schadet aber dann wohl auch nicht.

Ich verstehe die POSIX-Norm so, dass das funktionieren muss (auch mit
mehr als zwei Slashes in der Mitte oder am Ende). Ich hatte diesen Teil
|
| Multiple successive <slash> characters are considered to be the same
| as one <slash>, except for the case of exactly two leading <slash>
| characters.
Mehrere Slashes werden demnach überall zusammengefasst, außer am Anfang.

OK. Mir war nicht klar, ob sich das nur auf Slashes am Ende be-
zieht (siehe Dein erstes POSIX-Zitat oben).

In der Datei CONFIG steht übrigens:

| # Installation prefix (must be an absolute path without trailing slash)

Ist das an der Stelle denn anders als beim "-confprefix"?

Marcel

[Michael Bäuerle]

Post by Marcel Logen

Post by Michael Bäuerle

Post by Marcel Logen

Post by Michael Bäuerle

Post by Marcel Logen
PS: Zu -confprefix: Hier fände ich den Hinweis sinnvoll, daß
der entsprechende "path" ohne abschließenden Backslash an-
zugeben ist.

Das ist nicht der Fall. Ein abschließender Slash (nicht Backslash) ist
zulässig und funktioniert.

Ich meinte natürlich auch den "Slash".

Post by Michael Bäuerle
<https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271>
|
| A pathname can optionally contain one or more trailing <slash>
| characters. Multiple successive <slash> characters are considered
| to be the same as one <slash>, [...]

Aufgefallen war mir, daß im Falle des trailing slash im -confprefix
folgendes im Terminal angezeigt wird, wenn man (ein mit -debug ge-
| flnews: CONF: Store to: /home/user20/.config/flne-individual//configfile
Das schadet aber dann wohl auch nicht.

Ich verstehe die POSIX-Norm so, dass das funktionieren muss (auch mit
mehr als zwei Slashes in der Mitte oder am Ende). Ich hatte diesen Teil
|
| Multiple successive <slash> characters are considered to be the same
| as one <slash>, except for the case of exactly two leading <slash>
| characters.
Mehrere Slashes werden demnach überall zusammengefasst, außer am Anfang.

OK. Mir war nicht klar, ob sich das nur auf Slashes am Ende be-
zieht (siehe Dein erstes POSIX-Zitat oben).
| # Installation prefix (must be an absolute path without trailing slash)
Ist das an der Stelle denn anders als beim "-confprefix"?

Nein, das funktioniert dort auch mit Slash am Ende.
Das Build System hat das aber noch an mehreren anderen Stellen stehen.
Das überall freizugeben macht es schwieriger zu testen.

Ich habe nun doch in die man page geschrieben, dass man den Slash am
Ende für "confprefix" weglassen muss. So ist es wieder konsistent.