nntp-server mit user-accounts & gelesen-markierungen?

Post by Kay Martinen
Es gibt doch usenet-server software (ich meine via nntp) die
user-accounts erfordern, anbieten oder zumindest so konfiguriert werden
können das man sich vorher einloggen muß.

Natürlich.

Post by Kay Martinen
Dennoch speichert offenbar jeder nntp-client die liste der bereits
gelesenen artikel für sich lokal.

Das ist korrekt.

Post by Kay Martinen
Das ist natürlich dann unpraktisch
wenn man als User X von mehr als einem Client news lesen will.

Dafür gibt es als Quasi-Standard die .newsrc-Datei, die man ggf. zwischen
Clients, die das unterstützen, hin und her kopieren kann.

Post by Kay Martinen
Gibt es wirklich keinen nntp-server der das zentral pro user notiert?

Nein. Das wäre bei Servern mit zigtausend Newsgroups mit jeweils
hunderten, vielleicht auch zigtausend Artikeln und zigtausend Nutzern
nicht praktikabel.

Post by Kay Martinen
Sieht da das nntp-protokoll einfach nichts anderes vor?

Das Protokoll sieht das nicht vor, nein. Mit Grund.

Post by Kay Martinen
Kann es sein das dieses Feature einfach nicht mehr wichtig genug ist das
sich Programmierer mit dessen umsetzung/erweiterung befassen?

Jedenfalls INN wird durchaus noch weiterentwickelt. Bisher gibt es für
dieses Feature, AFAIS, aber weder in Servern noch in Clients
Unterstützung, kein Protokoll, keinen entsprechenden RFC und verschiedene
Gründe, die gegen die Umsetzung auf Serverseite sprechen.

-thh

--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>

Stefan+ (Stefan Froehlich)

2022-04-15 12:53:58 UTC

Post by Kay Martinen
Gibt es wirklich keinen nntp-server der das zentral pro user notiert?

Nein. Das wäre bei Servern mit zigtausend Newsgroups mit jeweils
hunderten, vielleicht auch zigtausend Artikeln und zigtausend
Nutzern nicht praktikabel.

IBTD: Meine .newsrc hat derzeit 114 Zeilen mit 36 kB; das wird für
die allermeisten User ganz ähnlich aussehen und nur für einen
verschwindend kleinen Teil davon gravierend schlimmer (i.e. mehr als
zwei Größenordnungen mehr bzw. mehr als 10k abonnierte Gruppen).

Ich sähe überhaupt kein Ressourcenproblem darin, das beim Server zu
speichern anstatt beim Client. Dagegen spricht einzig, aber

Post by Thomas Hochstein
Das Protokoll sieht das nicht vor, nein. Mit Grund.
Bisher gibt es für dieses Feature, AFAIS, aber weder in Servern
noch in Clients Unterstützung, kein Protokoll

...und es dürfte auch wenig Energie vorhanden sein, daran etwas zu
ändern. Auch wenn das für einige, wenige Anwender Vorteile hätte,
dem überwiegenden Teil wird es ziemlich egal sein, weil er a)
entweder nur einen Client verwendet oder b) einen lokalen Server.

Post by Thomas Hochstein
[...] verschiedene Gründe, die gegen die Umsetzung auf Serverseite
sprechen.

Ausser "ist aufwändig, wird aber kaum benötigt"?

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, so bockig wie die See. Da werden Jungenträume wahr!
(Sloganizer)

Kay Martinen

2022-04-15 14:57:39 UTC

Post by Kay Martinen
Gibt es wirklich keinen nntp-server der das zentral pro user notiert?

Nein. Das wäre bei Servern mit zigtausend Newsgroups mit jeweils
hunderten, vielleicht auch zigtausend Artikeln und zigtausend
Nutzern nicht praktikabel.

Ich hatte "gedanklich" so große Server nicht mit einbezogen denn...

Post by Stefan+ (Stefan Froehlich)
IBTD: Meine .newsrc hat derzeit 114 Zeilen mit 36 kB; das wird für
die allermeisten User ganz ähnlich aussehen und nur für einen
Ich sähe überhaupt kein Ressourcenproblem darin, das beim Server zu
speichern anstatt beim Client. Dagegen spricht einzig, aber

Post by Thomas Hochstein
Das Protokoll sieht das nicht vor, nein. Mit Grund.
Bisher gibt es für dieses Feature, AFAIS, aber weder in Servern
noch in Clients Unterstützung, kein Protokoll

... ich benutze einen Lokalen Server (Leafnode) der in meinem LAN sitzt
und da nur als eine Art Proxy auftritt. Der holt also nur die Gruppen
herein und sendet Posts raus, an einen großen Server.

Aber genau das wäre m-E. der usecase für das gefragte. Ein lokaler
Server und Client 1-x im LAN die drauf zugreifen mit nur einem user!

Post by Thomas Hochstein
[...] verschiedene Gründe, die gegen die Umsetzung auf Serverseite
sprechen.

Ausser "ist aufwändig, wird aber kaum benötigt"?

Wie aufwändig wäre es denn?

Man müsste ein RFC verfassen das eine Erweiterung des nntp beschreibt.
Man müsste ein o. mehr nntp-server und Clientproduzenten davon überzeugen...

... oder man müsste die Kenntnisse haben es selbst implementieren zu
können. Vielleicht erst auf dem Server und dann auf einem einfachen
nntp-client. Ich hab die Kenntnisse nicht!

Als Alternativen kommt hier wohl nur in Frage:

1. Es sein lassen!
2. EINEN Client in einer VM von X Geräten aus nutzen zu müssen.
3. Zwischen den clients immer wieder die newsrc zu syncen.

1. ist Faktisch. 2. Hat seine Eigenen "Herausforderungen" und 3. habe
ich ehrlich gesagt noch nicht probiert weil ich Probleme beim locking
erwarte wenn der Client grade läuft. U.a.

Darum wäre ich froh wenn jemand

4. es umsetzen würde.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

Stefan+ (Stefan Froehlich)

2022-04-15 18:14:40 UTC

Post by Kay Martinen

Post by Thomas Hochstein
[...] verschiedene Gründe, die gegen die Umsetzung auf
Serverseite sprechen.

Ausser "ist aufwändig, wird aber kaum benötigt"?

Wie aufwändig wäre es denn?
Man müsste ein RFC verfassen das eine Erweiterung des nntp
beschreibt.

Vor dem Verfassen des RFCs bräuchte man einmal ein sich in den
restlichen NNTP-Befehlssatz gut einfügendes Konzept. Keine unlösbare
Aufgabe, aber sie muss gelöst und danach in Text gekleidet werden.

Der ungleich größere Aufwand wäre wohl, diesen Text bis zur
Standards Track aufsteigen zu lassen (und solange er das nicht ist,
wird er kaum jemanden interessieren).

Post by Kay Martinen
Man müsste ein o. mehr nntp-server und Clientproduzenten davon überzeugen...

Auch das würde einiges an Aufwand verursachen (bei den Clients wohl
deutlich mehr als bei den Servern), aber siehe oben: Das muss
überhaupt erst einmal Thema werden.

Post by Kay Martinen
... oder man müsste die Kenntnisse haben es selbst implementieren
zu können. Vielleicht erst auf dem Server und dann auf einem
einfachen nntp-client. Ich hab die Kenntnisse nicht!

Sehr unpraktisch :-)

Denn: Wenn Du es nur für die Eigennutzung haben möchtest, bräuchtest
Du Dir die Mühe mit RFC et al gar nicht anzutun, sondern könntest
die Funktionalität einfach in die von Dir verwendete (OpenSource-)
Software hineinpatchen - dann sind auch die Anforderungen an
Konsistenz, Security etc nicht so gross.

Habe ich gelegentlich bei anderen Dingen schon getan, aber... sorry,
hier fehlt mir echt jeder Bedarf.

Post by Kay Martinen
Darum wäre ich froh wenn jemand
4. es umsetzen würde.

Naja, vielleicht liest das jemand und denkt sich: Coole Idee, mache
ich. Wetten würde ich darauf eher nicht.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan: das große Entzücken!
(Sloganizer)

Thomas Hochstein

2022-04-15 20:10:56 UTC

Post by Stefan+ (Stefan Froehlich)
Denn: Wenn Du es nur für die Eigennutzung haben möchtest, bräuchtest
Du Dir die Mühe mit RFC et al gar nicht anzutun, sondern könntest
die Funktionalität einfach in die von Dir verwendete (OpenSource-)
Software hineinpatchen - dann sind auch die Anforderungen an
Konsistenz, Security etc nicht so gross.

Es macht dann v.a. Sinn, das rein client-spezifisch zu machen, denn
vermutlich wird man auf allen Rechnern denselben Client nutzen - und dann
muss man sich überhaupt nicht mit Servern herumschlagen. Der einfachste
Weg ist dann wirklich ein Sync der .newsrc, wenn der Client eine solche
unterstützt. Das lässt sich ja beliebig automatisieren.

--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>

Michael Bäuerle

2022-04-16 09:36:51 UTC

Ich habe meine newsrc-Datei auf einem NFS-Server liegen. Die Newsreader
auf verschiedenen Rechnern verwenden diese zentrale Datei. Das ist
besser als nichts. Aber man muss immer noch aufpassen, dass der aktuelle
Stand auch auf dem Server liegt und man diesen nicht mit gleichzeitigem
Zugriff zerschießt. flnews verwendet hierzu POSIX advisory locks, aber
die funktionieren auf alten NFS-Implementierungen nicht immer.

Damit kann ich leben. Irgendeine schönere Lösung wäre aber durchaus
wünschenswert.
Die Sache ist irgendwie nicht schmerzhaft genug, als dass man da
richtig viel Arbeit investieren möchte (so geht es jedenfalls mir).

Peter J. Holzer

2022-04-19 10:15:51 UTC

Es macht dann v.a. Sinn, das rein client-spezifisch zu machen, denn
vermutlich wird man auf allen Rechnern denselben Client nutzen

slrn am Handy stelle ich mir eher unpraktisch vor.

Post by Thomas Hochstein
- und dann muss man sich überhaupt nicht mit Servern herumschlagen.
Der einfachste Weg ist dann wirklich ein Sync der .newsrc, wenn der
Client eine solche unterstützt. Das lässt sich ja beliebig
automatisieren.

Nicht ohne Server. Clients sind typischerweise hinter Firewalls oder
NATs und können nicht direkt miteinander kommunizieren.

Peter J. Holzer

2022-04-19 10:13:06 UTC

Post by Kay Martinen

Post by Thomas Hochstein
[...] verschiedene Gründe, die gegen die Umsetzung auf
Serverseite sprechen.

Ausser "ist aufwändig, wird aber kaum benötigt"?

Wie aufwändig wäre es denn?
Man müsste ein RFC verfassen das eine Erweiterung des nntp
beschreibt.

Vor dem Verfassen des RFCs bräuchte man einmal ein sich in den
restlichen NNTP-Befehlssatz gut einfügendes Konzept. Keine unlösbare
Aufgabe, aber sie muss gelöst und danach in Text gekleidet werden.
Der ungleich größere Aufwand wäre wohl, diesen Text bis zur
Standards Track aufsteigen zu lassen (und solange er das nicht ist,
wird er kaum jemanden interessieren).

Gerade bei NNTP wurde jahrzehntelang ohne RFCs entwickelt (RFC 977 ist
von 1986, der Nachfolger 3977 von 2006, RFC 1036 von 1987, die
Nachfolger 5536 und 5537 von 2009). Also eigentlich die ganze Zeit, in
der das Usenet gelebt hat. Neue RFCs, die die Entwicklung dokumentieren,
gab es erst, als das Usenet zumindest schon etwas streng gerochen hat.

Ob gerade beim Usenet jemanden ein Standards Track RFC jemanden mehr
interessiert als ein Experimental RFC oder ein funktionierender Patch
für den INN und ein oder zwei Clients, ist mehr als fraglich.

Post by Stefan+ (Stefan Froehlich)
Habe ich gelegentlich bei anderen Dingen schon getan, aber... sorry,
hier fehlt mir echt jeder Bedarf.

Wenn es einen brauchbaren News-Client fürs Handy gäbe, würde ich den
Bedarf sehen. So ist mir mein Workaround (SSH zu dem Rechner, auf dem
ich slrn installiert habe) gut genug. Aber da ist ein bisschen ein
Henne-Ei-Problem involviert: Denn ein Feature, das ein News-Client fürs
Handy haben müsste, um für mich brauchbar zu sein, ist genau diese
Synchronisation ...

hp

Christian Garbs

2022-04-15 21:08:41 UTC

Mahlzeit!

Post by Kay Martinen
1. Es sein lassen!
2. EINEN Client in einer VM von X Geräten aus nutzen zu müssen.
3. Zwischen den clients immer wieder die newsrc zu syncen.
1. ist Faktisch. 2. Hat seine Eigenen "Herausforderungen" und 3. habe
ich ehrlich gesagt noch nicht probiert weil ich Probleme beim locking
erwarte wenn der Client grade läuft. U.a.

Ich habe Variante 2a im Einsatz:

Ich betreibe einen inn2 auf einem lokalen Server. Auf dem gleichen
Server lese ich die News per tin(1) über eine SSH-Verbindung. So habe
ich nur eine .newsrc und muss nichts syncen. SSH-Zugriff kriege ich
einfach organisiert (ich wechsele regelmäßig meinen Standort) und muss
nicht mit VMs hantieren.

Newsreader für den Textmodus gibt's ja einige.

Gruß
Christian

--
....Christian.Garbs....................................https://www.cgarbs.de
Das, was landläufig als eMail bezeichnet wird, müßte korrekterweise
eigentlich eLetter betitelt werden.

Diedrich Ehlerding

2022-04-15 16:03:41 UTC

Post by Kay Martinen
... ich benutze einen Lokalen Server (Leafnode) der in meinem LAN
sitzt und da nur als eine Art Proxy auftritt. Der holt also nur die
Gruppen herein und sendet Posts raus, an einen großen Server.
Aber genau das wäre m-E. der usecase für das gefragte. Ein lokaler
Server und Client 1-x im LAN die drauf zugreifen mit nur einem user!

Und für so einen lokalen Server möchtest du ein neues Protokoll
entwickeln? EWin Protokoll, das sowohl im Server als auch in den
Clienbts ebenfalls implementiert werden mpüsste?

Wenn du schon einen lokalen Newsserver benutzt, was hindert dich denn
dann daran, den .newsrc-Mechanismus zu nutzen? Dass deine Clients den
nicht benutzem? Ach, dann müsstest du doch nur in den Clients mal eben
was nachimplementieren, nicht auf Client- /und/ Serverseite, wie bei
deinem Vorschlag.

--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

Peter J. Holzer

2022-04-19 10:01:31 UTC

Und für so einen lokalen Server möchtest du ein neues Protokoll
entwickeln? EWin Protokoll, das sowohl im Server als auch in den
Clienbts ebenfalls implementiert werden mpüsste?

Ja, natürlich. Wenn ein Client und ein Server miteinander reden sollen,
brauchst Du ein Protokoll (auch wenn mehrerere "Clients" P2P miteinander
reden sollen, brauchst Du ein Protokoll.

Die Intention sollte natürlich schon sein, ein Protokoll zu entwickeln,
das nicht nur Kai verwenden kann, sondern beliebige User mit ihren
Clients und Servern (was z.B. bedeutet, dass man den Fall, dass ein
Server mehrere User hat, abdecken muss).

Post by Diedrich Ehlerding
Wenn du schon einen lokalen Newsserver benutzt, was hindert dich denn
dann daran, den .newsrc-Mechanismus zu nutzen? Dass deine Clients den
nicht benutzem?

Es gibt m.W. keinen standardisierten Mechanismus, mit dem mehrere
Clients P2P ihre .newsrc-Files abgleichen. Du kannst das File auf
Nextcloud oder Dropbox legen oder irgendwas mit rsync oder unison
basteln, aber das ist außerhalb des Clients.

Post by Diedrich Ehlerding
Ach, dann müsstest du doch nur in den Clients mal eben
was nachimplementieren, nicht auf Client- /und/ Serverseite, wie bei
deinem Vorschlag.

Macht vom Aufwand her keinen Unterschied (außer Du hast nur einen
Client, aber wozu dann das ganze?) und typischerweise haben Clients
keine direkten Kontakt zueinander, du brauchst also erst wieder einen
Server.

hp

Diedrich Ehlerding

2022-04-19 14:30:41 UTC

Post by Kay Martinen
Aber genau das wäre m-E. der usecase für das gefragte. Ein lokaler
Server und Client 1-x im LAN die drauf zugreifen mit nur einem user!

Und für so einen lokalen Server möchtest du ein neues Protokoll
entwickeln? EWin Protokoll, das sowohl im Server als auch in den
Clienbts ebenfalls implementiert werden mpüsste?

Ja, natürlich. Wenn ein Client und ein Server miteinander reden
sollen, brauchst Du ein Protokoll (auch wenn mehrerere "Clients" P2P
miteinander reden sollen, brauchst Du ein Protokoll.

Ja- Genau das schrieb ich ja. Für Kays Wunsch müsste auf Client- und auf
Serverseite ein Protokoll implementiert werden, und zwar, wenn es
sinnvoll nutzbar sein soll, in vielen Clients und etlichen Servern. Und
sowohl Clients müssten auch das alte, bisherige nntp beherrschen (wenn
sie auf einen Server angesetzt werden, der das noch nicht kann), als
auch die server (weil ja jemand mit einem alten Client ankommen könnte.

Wie lange ist schon IPv6 und IPv4 paallel in Betrieb? Wie lange laufen
schon die diversen Versionen von cifs oder nfs parallel, und keiner
tarut sich, die alten Versionen abzuklemmen?

Post by Peter J. Holzer
Die Intention sollte natürlich schon sein, ein Protokoll zu
entwickeln, das nicht nur Kai verwenden kann, sondern beliebige User
mit ihren Clients und Servern (was z.B. bedeutet, dass man den Fall,
dass ein Server mehrere User hat, abdecken muss).

Eben. Wer sollte das tun, und warum? Außer Kay scheint niemand danach zu
lechzen.

Post by Diedrich Ehlerding
Wenn du schon einen lokalen Newsserver benutzt, was hindert dich denn
dann daran, den .newsrc-Mechanismus zu nutzen? Dass deine Clients den
nicht benutzem?

Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
greifen dort hin. Ja, das ist außerhalb des Clients - um so besserm,
dann braucht man nämlcih nicht nicht einmal dieClients anzufassen, die
den .newsrc-Mechanismus schon kennen. Und die anderen Clients müsste man
in Kays Träumen von einem neuen Protokoll ja eh anfassen; das Gedächtnis
im .newsrc-Format aufzubauen dürfte deutlich weniger Aufwanbd sein als
inn, leafnode, hamster, cnews usw. alle mit neuem Protokoll zu erweitern
und dann die Clients ebenfalls anzufassen.

Außerdem redet Kay von einem lokalen leafnode, an den er sich mit
verschiedenen Clients wenden will. Ja verdorri nochmal, dann msus er da
im schlimmsten Fall ein paar .newsrc hinundherkopieren, d.h. seine
Clients in ein Skript verpacken, das vorher die .newsrc holt und ggf.
zum passenden Format ändert und dann wieder zurückkopiert.

Post by Diedrich Ehlerding
Ach, dann müsstest du doch nur in den Clients mal eben
was nachimplementieren, nicht auf Client- /und/ Serverseite, wie bei
deinem Vorschlag.

Macht vom Aufwand her keinen Unterschied

Es ist halt nur doppelter Aufwand ... aber wenn du meinst, es sei so
trivial, das auf Serverseite zusätzlich zu implementieren, dann mach
doch. Viel Spaß ... und wundere dich nicht, wenn das Interesse für deine
Erweiterungen übersichtlich bleibt.

Post by Peter J. Holzer
(außer Du hast nur einen
Client, aber wozu dann das ganze?)

Eben - wozu das Ganze?

Post by Peter J. Holzer
und typischerweise haben Clients
keine direkten Kontakt zueinander, du brauchst also erst wieder einen
Server.

Nö - es reicht, wenn die die .newsrc verstehen und befüllen.

--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

Peter J. Holzer

2022-04-22 18:28:23 UTC

Post by Diedrich Ehlerding
Wenn du schon einen lokalen Newsserver benutzt, was hindert dich denn
dann daran, den .newsrc-Mechanismus zu nutzen? Dass deine Clients den
nicht benutzem?

Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
greifen dort hin.

Dazu braucht man einen Fileserver.

Post by Peter J. Holzer
und typischerweise haben Clients keine direkten Kontakt zueinander,
du brauchst also erst wieder einen Server.

Nö - es reicht, wenn die die .newsrc verstehen und befüllen.

Nein. Ohne den Fileserver (oder einen anderen Mittelsmann) hat jeder
Client nur sein eigenes .newsrc. Für eine gemeinsame Datenbasis brauchst
Du im Allgemeinen einen Server (reines P2P ist im heutigen Internet eher
schwierig).

Post by Diedrich Ehlerding
Ach, dann müsstest du doch nur in den Clients mal eben was
nachimplementieren, nicht auf Client- /und/ Serverseite, wie bei
deinem Vorschlag.

Macht vom Aufwand her keinen Unterschied

Es ist halt nur doppelter Aufwand ...

Doppelter nicht, denn 2 Seiten hast Du mindestens, sonst ist es keine
Kommunikation. Der Server wäre dann die dritte, also 50 % mehr. Und P2P
ist um vieles komplizierter als Client-Server-Kommunikation. In Summe
ist es wahrscheinlich sogar weniger Aufwand mit Server als ohne.

Post by Diedrich Ehlerding
aber wenn du meinst, es sei so trivial, das auf Serverseite zusätzlich
zu implementieren, dann mach doch.

Ich habe nicht geschrieben, dass es trivial wäre. Obwohl - sonderlich
kompliziert sollte es wirklich nicht sein. Im Prinzip muss ja nur jeder
Client sein .newsrc laden und speichern können, eventuell mit
server-seitigem Merge.

Post by Diedrich Ehlerding
Viel Spaß ... und wundere dich nicht, wenn das Interesse für deine
Erweiterungen übersichtlich bleibt.

Das mangelnde Interesse an der Weiterentwicklung des Usenet hält mich
seit fast 20 Jahren davon ab, Arbeit zu investieren. Das ist nicht nur
eine kleine Community, sondern außerdem noch eine extrem zersplitterte
und konservative.

hp

Diedrich Ehlerding

2022-04-22 18:34:17 UTC

Post by Diedrich Ehlerding
Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
greifen dort hin.

Dazu braucht man einen Fileserver.

Post by Peter J. Holzer
und typischerweise haben Clients keine direkten Kontakt zueinander,
du brauchst also erst wieder einen Server.

Nö - es reicht, wenn die die .newsrc verstehen und befüllen.

Nein. Ohne den Fileserver (oder einen anderen Mittelsmann) hat jeder
Client nur sein eigenes .newsrc. Für eine gemeinsame Datenbasis
brauchst Du im Allgemeinen einen Server (reines P2P ist im heutigen
Internet eher schwierig).

Kay Martinen, der dieses Thema aufgebracht hat, sprach davon, dass er
einen leafnode in seinem lokalen LAN betreibt und den als Newsserver
nutzt. Das ist also wahrscheinlich ein Linux, auf jeden Fall etwas
Unixoides (theoretisch kann es auch ein bsd sein; auch auf Solaris habe
ich mal einen leafnode übersetzt. Damit hat er also einen Fileserver,
bzw. könnte da einen betreiben.

--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

Peter J. Holzer

2022-04-23 10:15:30 UTC

Post by Peter J. Holzer
du brauchst also erst wieder einen Server.

Nö

Damit hat er also einen Fileserver, bzw. könnte da einen betreiben.

Die Tatsache, dass er einen Server hat (oder haben könnte), macht die
Aussage, dass er einen braucht, nicht falsch.

hp

Diedrich Ehlerding

2022-04-23 14:40:46 UTC

Post by Peter J. Holzer
du brauchst also erst wieder einen Server.

Nö

Damit hat er also einen Fileserver, bzw. könnte da einen betreiben.

Die Tatsache, dass er einen Server hat (oder haben könnte), macht die
Aussage, dass er einen braucht, nicht falsch

Ich habe ja auch nicht gesagt, dass er keinen braucht, sondern dass er
bereits einen hat, den er verwenden kann,

--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

Stefan+ (Stefan Froehlich)

2022-04-23 07:07:48 UTC

Post by Diedrich Ehlerding
wenn du meinst, es sei so trivial, das auf Serverseite zusätzlich
zu implementieren, dann mach doch.

Ich habe nicht geschrieben, dass es trivial wäre. Obwohl -
sonderlich kompliziert sollte es wirklich nicht sein. Im Prinzip
muss ja nur jeder Client sein .newsrc laden und speichern können,
eventuell mit server-seitigem Merge.

Das wäre die Basisfunktionalität, aber sinnvollerweise sollten
ARTICLE und BODY auch gleich server-intern den entsprechenden
Artikel auf "gelesen" setzen, weiters sollte entweder LISTGROUP
hinter jedem Posting den Status ausgeben und/oder durch einen
zusätzlichen Parameter nur die ungelesenen Postings anzeigen.

Immer noch sehr überschaubarer Aufwand, aber dann könnte man mit
sehr wenig Mühe client-seitig auch komplett auf eine .newsrc
verzichten.

Post by Peter J. Holzer
Das mangelnde Interesse an der Weiterentwicklung des Usenet hält mich
seit fast 20 Jahren davon ab, Arbeit zu investieren.

Nachvollziehbar. Zudem funktioniert es ja (wenigstens für mich, aber
auch für alle anderen mit nur einem Newsreader) auch jetzt schon
genauso gut.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - das zweisamste Überraschungsgeschenk seit Helmut Kohl.
(Sloganizer)

Laurenz Trossel

2022-04-23 07:57:42 UTC

Post by Stefan+ (Stefan Froehlich)
Das wäre die Basisfunktionalität, aber sinnvollerweise sollten
ARTICLE und BODY auch gleich server-intern den entsprechenden
Artikel auf "gelesen" setzen,

Und wie setzt man einen Artikel dann wieder auf "ungelesen"?

Post by Stefan+ (Stefan Froehlich)
weiters sollte entweder LISTGROUP
hinter jedem Posting den Status ausgeben

Bestehende Kommandos zu modifizieren, kann zu ungewollten Problemen mit
bestehender Software führen. Besser wird dafür ein neues Kommando
definiert.

Post by Stefan+ (Stefan Froehlich)
Immer noch sehr überschaubarer Aufwand, aber dann könnte man mit
sehr wenig Mühe client-seitig auch komplett auf eine .newsrc
verzichten.

Das kann man bei IMAP schon lange.

Stefan+ (Stefan Froehlich)

2022-04-23 08:48:14 UTC

Post by Laurenz Trossel

Post by Stefan+ (Stefan Froehlich)
Das wäre die Basisfunktionalität, aber sinnvollerweise sollten
ARTICLE und BODY auch gleich server-intern den entsprechenden
Artikel auf "gelesen" setzen,

Und wie setzt man einen Artikel dann wieder auf "ungelesen"?

Durch den Befehl UNREAD, den ich nicht erwähnt hatte :-)

Post by Laurenz Trossel

Post by Stefan+ (Stefan Froehlich)
weiters sollte entweder LISTGROUP hinter jedem Posting den Status
ausgeben

Bestehende Kommandos zu modifizieren, kann zu ungewollten
Problemen mit bestehender Software führen. Besser wird dafür ein
neues Kommando definiert.

Eine (neue) Option zu LISTGROUP gefiele mir besser, um einen
Wildwuchs im Befehlssatz zu verhindern - dann gäbe es auch keine
Kompatibilitätsprobleme (die Chance, dass bestehende Software die
noch nicht existente Option triggert ist gleich klein wie das
Absetzen eines noch nicht existierenden Kommandos).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

So ein ernster Gedanke: Stefan!
(Sloganizer)

Martin Burmester

2022-04-27 10:54:54 UTC

Hallo,

Post by Diedrich Ehlerding
Wenn du schon einen lokalen Newsserver benutzt, was hindert dich denn
dann daran, den .newsrc-Mechanismus zu nutzen? Dass deine Clients den
nicht benutzem?

Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
greifen dort hin.

Dazu braucht man einen Fileserver.

Post by Peter J. Holzer
und typischerweise haben Clients keine direkten Kontakt zueinander,
du brauchst also erst wieder einen Server.

Nö - es reicht, wenn die die .newsrc verstehen und befüllen.

Wahrscheinlich die einfachste Lösung wäre die newsrc Datei per WebDAV
auf einen Webserver zu legen. Da müsste dann "nur" die clients anpassen
und würde auf bestehende Protokolle aufbauen ohne alles umzuwerfen.

Grüße
Martin

Thomas Hochstein

2022-04-15 20:07:56 UTC

Post by Thomas Hochstein
[...] verschiedene Gründe, die gegen die Umsetzung auf Serverseite
sprechen.

Ausser "ist aufwändig, wird aber kaum benötigt"?

Einerseits das; der Aufwand erschöpft sich aber nicht nur in
Speicherplatz. Es bedarf einer komplett neuen Datenbank, die den Status
für jedes Posting in jeder Gruppe für jeden Nutzer hält, und die mit dem
Expire synchronisiert werden muss. Und natürlich braucht es ein Protokoll,
um den Status zwischen Client und Server zu synchronisieren - regelmäßig,
denn ich kann ja im Client eine ganze Gruppe als gelesen markieren, aber
auch einzelne Postings wieder als ungelesen setzen.

Und das betrifft nur Online-Newsreader. Mindestens so gebräuchlich sind
aber Offline-Clients. Ich verbinde mich also mit Client A und rufe neue
Postings ab. Danach werden sie lokal gefiltert, manche vielleicht schon
automatisch auf gelesen gesetzt oder gelöscht. Ich gehe offline, lese
einige Beiträge und setze andere wieder auf ungelesen. - Jetzt verbinde
ich mich mit Client B, bekomme neue Postings, lese einige, gehe offline.
Jetzt verbinde ich mich wieder mit Client A. Bekommt der jetzt den Status
vom Server, oder übermittelt er seinen Status an den Server? ;)

Und jetzt kommen die Clients, die mehrere Newsserver unterstützen. Wer
hält jetzt wie den Status zentral nach? Auf welchem Server wird welches
Posting als gelesen markiert, wenn ich es im Client auf gelesen setze? ;)

-thh

--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>

Stefan+ (Stefan Froehlich)

2022-04-15 20:59:56 UTC

Post by Thomas Hochstein
[...] verschiedene Gründe, die gegen die Umsetzung auf Serverseite
sprechen.

Ausser "ist aufwändig, wird aber kaum benötigt"?

Und das betrifft nur Online-Newsreader. Mindestens so gebräuchlich
sind aber Offline-Clients. [...]

Stimmt, das hatte ich ja komplett verdrängt, da ich seit 25 Jahren
keinen offline-Reader mehr verwendet habe. Entweder müsste man die
aussen vor lassen (dann wird "kaum benötigt" noch weniger), oder es
würde deutlich komplizierter werden.

Insgesamt jedenfalls eine Lösung, für die es (wie man sieht: fast)
nirgendwo ein passendes Problem gibt.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - die königlichste Idee, die es je gab.
(Sloganizer)

Thomas Hochstein

2022-04-16 05:56:41 UTC

Post by Stefan+ (Stefan Froehlich)
Insgesamt jedenfalls eine Lösung, für die es (wie man sieht: fast)
nirgendwo ein passendes Problem gibt.

So würde ich das nicht sagen; ich habe das Problem viele Jahre gehabt,
über ein Jahrzehnt dadurch "gelöst", dass ich News (und Mail!)
ausschließlich am Laptop bearbeitet habe [1] und fände eine Lösung sehr
praktisch (sowohl für den Umstieg auf den Laptop im Urlaub [2] als auch um
mal einen anderen Newsreader auszuprobieren, ohne sofort komplett zu
wechseln).

Da aber ohnehin Änderungen an jedem Client erforderlich wären, schiene mir
ein rein client-basiertes Protokoll die bessere und einfachere Lösung. Da
würde sich .newsrc o.ä. anbieten. [3]

-thh

[1]
<https://netz-rettung-recht.de/archives/2385-News-Mail-gestern,-heute-morgen.html#history>

[2] Fallback-"Lösung": Komplette Konfiguration und Datenbank kopieren.
Obwohl ich Newsgroups nur ~ 1 Jahr halte, lösche ich Mails nicht mehr
regelmäßig jedes Jahr nach dem Anlegen einer Archiv-Instanz, so dass das
derzeit > 15 GB sind. Als regelmäßige "Lösung" mithin untauglich.

[3] Ich vermeinte, dass Agent das sogar unterstützt - das war aber ein
Irrtum or a thing of the past: "Agent 8 does not support newsrc files".

--
Informationen rund um Usenet und Newsserver:
<https://th-h.de/net/usenet/>

Laurenz Trossel

2022-04-16 04:00:24 UTC

Post by Thomas Hochstein
Einerseits das; der Aufwand erschöpft sich aber nicht nur in
Speicherplatz. Es bedarf einer komplett neuen Datenbank, die den Status
für jedes Posting in jeder Gruppe für jeden Nutzer hält, und die mit dem
Expire synchronisiert werden muss. Und natürlich braucht es ein Protokoll,
um den Status zwischen Client und Server zu synchronisieren

Es gibt IMAP.

Peter J. Holzer

2022-04-19 10:20:35 UTC

Post by Kay Martinen
Gibt es wirklich keinen nntp-server der das zentral pro user notiert?

Nein. Das wäre bei Servern mit zigtausend Newsgroups mit jeweils
hunderten, vielleicht auch zigtausend Artikeln und zigtausend Nutzern
nicht praktikabel.

Das war vielleicht 1995 ein Problem, Selbst wenn ein .newsrc 1 MB groß
ist und Du 10000 User hast, sind das erst 10 GB. Vernachlässigbar. Und
die Zahl der Newsserver mit 10000 Usern dürfte heute eher beschränkt
sein.

hp

Henning Hucke

2022-04-16 13:44:43 UTC