Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
nntp-server mit user-accounts & gelesen-markierungen?
2 views
Skip to first unread message
Kay Martinen
Apr 15, 2022, 5:20:02 AM4/15/22
to
Hallo
Einen Besinnlichen Karfreitag und Frohe Ostern vorab.
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ß. SN kann einen User, INN wohl
mehr und bei Leafnode bin ich nicht sicher. Gibt es noch andere?
Dennoch speichert offenbar jeder nntp-client die liste der bereits
gelesenen artikel für sich lokal. Das ist natürlich dann unpraktisch
wenn man als User X von mehr als einem Client news lesen will. Man kann
dann eigentlich nur nach dem letzten Lesedatum gehen das man auch erst
mal präsent haben müsste. Weil Client 2 ja ein anderes haben wird als
Client 1 an dem man zuletzt las. Eine Zentrale speicherung auf dem
Server und austausch zum Jew. Client des Users würde das lösen.
Fragen:
Gibt es wirklich keinen nntp-server der das zentral pro user notiert?
Fehlt da evtl. "nur" ein Client/SW diese Info dem Server zu senden?
Oder umgekehrt ein Client der diese vom Server anfordert?
Sieht da das nntp-protokoll einfach nichts anderes vor?
Kann es sein das dieses Feature einfach nicht mehr wichtig genug ist das
sich Programmierer mit dessen umsetzung/erweiterung befassen?
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Einen Besinnlichen Karfreitag und Frohe Ostern vorab.
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ß. SN kann einen User, INN wohl
mehr und bei Leafnode bin ich nicht sicher. Gibt es noch andere?
Dennoch speichert offenbar jeder nntp-client die liste der bereits
gelesenen artikel für sich lokal. Das ist natürlich dann unpraktisch
wenn man als User X von mehr als einem Client news lesen will. Man kann
dann eigentlich nur nach dem letzten Lesedatum gehen das man auch erst
mal präsent haben müsste. Weil Client 2 ja ein anderes haben wird als
Client 1 an dem man zuletzt las. Eine Zentrale speicherung auf dem
Server und austausch zum Jew. Client des Users würde das lösen.
Fragen:
Gibt es wirklich keinen nntp-server der das zentral pro user notiert?
Fehlt da evtl. "nur" ein Client/SW diese Info dem Server zu senden?
Oder umgekehrt ein Client der diese vom Server anfordert?
Sieht da das nntp-protokoll einfach nichts anderes vor?
Kann es sein das dieses Feature einfach nicht mehr wichtig genug ist das
sich Programmierer mit dessen umsetzung/erweiterung befassen?
Ｂｙｅ／
／Ｋａｙ
--
"Kann ein Wurstbrot die Welt retten?" :-)
Thomas Hochstein
Apr 15, 2022, 8:00:03 AM4/15/22
to
Kay Martinen schrieb:
> 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.
> Dennoch speichert offenbar jeder nntp-client die liste der bereits
> gelesenen artikel für sich lokal.
Das ist korrekt.
> 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.
> Fragen:
> 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.
> Sieht da das nntp-protokoll einfach nichts anderes vor?
Das Protokoll sieht das nicht vor, nein. Mit Grund.
> 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/>
> 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ß.
> Dennoch speichert offenbar jeder nntp-client die liste der bereits
> gelesenen artikel für sich lokal.
> Das ist natürlich dann unpraktisch
> wenn man als User X von mehr als einem Client news lesen will.
Clients, die das unterstützen, hin und her kopieren kann.
> Fragen:
> Gibt es wirklich keinen nntp-server der das zentral pro user notiert?
hunderten, vielleicht auch zigtausend Artikeln und zigtausend Nutzern
nicht praktikabel.
> Sieht da das nntp-protokoll einfach nichts anderes vor?
> Kann es sein das dieses Feature einfach nicht mehr wichtig genug ist das
> sich Programmierer mit dessen umsetzung/erweiterung befassen?
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 Froehlich
Apr 15, 2022, 8:54:00 AM4/15/22
to
On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
>> Fragen:
>> 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
>> Fragen:
>> 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.
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
entscheidend, das hier:
> 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
> noch in Clients Unterstützung, kein Protokoll
ä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.
> [...] 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
Apr 15, 2022, 11:00:02 AM4/15/22
to
Am 15.04.22 um 14:53 schrieb 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
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!
>> [...] 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.
> On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
>>> Fragen:
>>> 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...
>>> Fragen:
>>> 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
> Ich sähe überhaupt kein Ressourcenproblem darin, das beim Server zu
> speichern anstatt beim Client. Dagegen spricht einzig, aber
> entscheidend, das hier:
>
>> 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.
... ich benutze einen Lokalen Server (Leafnode) der in meinem LAN sitzt
> speichern anstatt beim Client. Dagegen spricht einzig, aber
> entscheidend, das hier:
>
>> 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.
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!
>> [...] verschiedene Gründe, die gegen die Umsetzung auf Serverseite
>> sprechen.
>
> Ausser "ist aufwändig, wird aber kaum benötigt"?
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.
Stefan Froehlich
Apr 15, 2022, 2:14:43 PM4/15/22
to
On Fri, 15 Apr 2022 16:57:39 Kay Martinen wrote:
> Am 15.04.22 um 14:53 schrieb Stefan Froehlich:
>> On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
>>> [...] 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
> Am 15.04.22 um 14:53 schrieb Stefan Froehlich:
>> On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
>>> [...] 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.
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).
> Man müsste ein o. mehr nntp-server und Clientproduzenten davon
> überzeugen...
deutlich mehr als bei den Servern), aber siehe oben: Das muss
überhaupt erst einmal Thema werden.
> ... 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!
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.
> Darum wäre ich froh wenn jemand
> 4. es umsetzen würde.
ich. Wetten würde ich darauf eher nicht.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
(Sloganizer)
Thomas Hochstein
Apr 15, 2022, 4:15:02 PM4/15/22
to
Stefan Froehlich schrieb:
> 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.
> 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.
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.
Thomas Hochstein
Apr 15, 2022, 4:15:02 PM4/15/22
to
Stefan Froehlich schrieb:
> On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
> > [...] 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? ;)
> On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
> > [...] verschiedene Gründe, die gegen die Umsetzung auf Serverseite
> > sprechen.
>
> Ausser "ist aufwändig, wird aber kaum benötigt"?
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? ;)
Stefan Froehlich
Apr 15, 2022, 4:59:59 PM4/15/22
to
On Fri, 15 Apr 2022 22:07:56 Thomas Hochstein wrote:
> Stefan Froehlich schrieb:
>> On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
>> > [...] verschiedene Gründe, die gegen die Umsetzung auf Serverseite
>> > sprechen.
>> Ausser "ist aufwändig, wird aber kaum benötigt"?
> Stefan Froehlich schrieb:
>> On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
>> > [...] 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
(Sloganizer)
Christian Garbs
Apr 15, 2022, 5:08:42 PM4/15/22
to
Mahlzeit!
Kay Martinen <use...@martinen.de> wrote:
> 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.
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.
Kay Martinen <use...@martinen.de> wrote:
> 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.
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.
Laurenz Trossel
Apr 16, 2022, 12:00:25 AM4/16/22
to
On 2022-04-15, Thomas Hochstein <t...@thh.name> wrote:
> 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.
> 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
Thomas Hochstein
Apr 16, 2022, 2:00:03 AM4/16/22
to
Stefan Froehlich schrieb:
> 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".
> Insgesamt jedenfalls eine Lösung, für die es (wie man sieht: fast)
> nirgendwo ein passendes Problem gibt.
ü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".
Diedrich Ehlerding
Apr 16, 2022, 3:41:11 AM4/16/22
to
Kay Martinen meinte:
> ... 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.
> ... 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!
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.
Michael Bäuerle
Apr 16, 2022, 5:37:16 AM4/16/22
to
Thomas Hochstein wrote:
> Stefan Froehlich schrieb:
> >
> > 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.
Ich habe meine newsrc-Datei auf einem NFS-Server liegen. Die Newsreader
> Stefan Froehlich schrieb:
> >
> > 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.
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).
Henning Hucke
Apr 16, 2022, 10:37:46 AM4/16/22
to
On 2022-04-15, Kay Martinen <use...@martinen.de> wrote:
> Hallo
Hallo selbst,
> [...]
sie noch sinnvoll weiterentwickelt werden, ist eine andere Frage.
INN, DNews, CNews und ähnliche sind News-Server ("usenet" ist eine
Hierarchie von Gruppen, NNTP ist ein aber potentiell nicht das einzige
Zugriffsprotokoll für News), die für das Hosting von Newsgroups gedacht
sind. Da News ein verteiltes System ist - man kann auf einem Server "in
der Nähe" grundsätzlich die selben News genauso lesen, wie im Urlaub
"auf der andere Seite der Welt" auf einem ebenfalls "in der Nähe"
gelegenen Newsserver -, werden Postings zwischen den Newsservern
"synchronisiert". In der Regel passiert das mittels des Network News
Transfer Protocol (NNTP). Clients verwenden hysterisch gewachsen
ebenfalls das NNTP mit ein paar Modifikationen.
Inzwischen existieren für den ein oder anderen Internet Mail Access
Protocol Server (IMAP Server) IMAP2NNTP-Gateways, die das von Dir
gewünschte bei Verwendung eines IMAP-Clients leisten können.
Naturgemäß sind IMAP-Clients nicht für den Umgang mit News optimiert,
wodurch der Umgang mit einigen Features der News umständlicher oder
teilweise nicht möglich ist.
> Dennoch speichert offenbar jeder nntp-client die liste der bereits
> gelesenen artikel für sich lokal. Das ist natürlich dann unpraktisch
> wenn man als User X von mehr als einem Client news lesen will. Man kann
> dann eigentlich nur nach dem letzten Lesedatum gehen das man auch erst
> mal präsent haben müsste. Weil Client 2 ja ein anderes haben wird als
> Client 1 an dem man zuletzt las. Eine Zentrale speicherung auf dem
> Server und austausch zum Jew. Client des Users würde das lösen.
Ja, klar. Natürlich würde das das Problem lösen ist aber ein typisches
denken in zentralen Strukturen.
Seit einiger Zeit existieren DNS-basierte Methoden, Server für
verschiedenste Dienste transparent zu ermitteln / ausfindig zu machen.
Modernere News-Clients dürfen diese Implementieren. Entsprechend würdest
Du (per default) im Urlaub auf einem anderen News-Server lesen (und
potentiell schreiben), als zuhause.
Die Weiterungen bezüglich des Gelesen-Status für Postings kannst Du dir
denken...
> Fragen:
> Gibt es wirklich keinen nntp-server der das zentral pro user notiert?
> Fehlt da evtl. "nur" ein Client/SW diese Info dem Server zu senden?
> Oder umgekehrt ein Client der diese vom Server anfordert?
> Sieht da das nntp-protokoll einfach nichts anderes vor?
Nein, weil es in keinster Weise sinnvoll ist.
Abseits der Verwendung eines IMAP-Server mit IMAP2NNTP-Gateway ist die
Entwicklung eines "Schwester-Protokolls" denkbar, dass den
Gelesen-Status in einem - gegebenenfalls ebenfalls verteilten - System
speichert und in dem man einen entsprechenden Account hat. Das würde
dann das NewsRC-File ersetzen bzw. zu dessen Synchronisierung dienen.
Ein solches Vorgehen hätte sogar noch den Vorteil, dass man über einen
lokal laufenden User-spezifischen Daemon selbst klassische NewsRC-Files
synchronisieren könnte, sodass auch klassische Newsreader mit dem
aktuellen Stand arbeiten würden.
> Kann es sein das dieses Feature einfach nicht mehr wichtig genug ist das
> sich Programmierer mit dessen umsetzung/erweiterung befassen?
Bedauerlicherweise sind News bei weitem nicht mehr so beliebt, wie das
mal der Fall war. Entsprechend würde ich davon ausgehen, dass eine
vernünftige Implementierung der von Dir gewünschten Funktionalität
nichts mit "Wichtigkeit" zu tun hat, sondern mit einer unterkritischen
Masse an Entwicklern, die an der Entwicklung und Implemtierung eines
neuen (Hilfs-) Prototolls interesse hätten.
> [...]
Mit freundlichem Gruß,
Henning
--
Can't open /usr/fortunes. Lid stuck on cookie jar.
> Hallo
Hallo selbst,
> [...]
> 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ß. SN kann einen User, INN wohl
> mehr und bei Leafnode bin ich nicht sicher. Gibt es noch andere?
Es gibt sicherlich noch andere. Aber in welchem Zustand die sind und ob
> user-accounts erfordern, anbieten oder zumindest so konfiguriert werden
> können das man sich vorher einloggen muß. SN kann einen User, INN wohl
> mehr und bei Leafnode bin ich nicht sicher. Gibt es noch andere?
sie noch sinnvoll weiterentwickelt werden, ist eine andere Frage.
INN, DNews, CNews und ähnliche sind News-Server ("usenet" ist eine
Hierarchie von Gruppen, NNTP ist ein aber potentiell nicht das einzige
Zugriffsprotokoll für News), die für das Hosting von Newsgroups gedacht
sind. Da News ein verteiltes System ist - man kann auf einem Server "in
der Nähe" grundsätzlich die selben News genauso lesen, wie im Urlaub
"auf der andere Seite der Welt" auf einem ebenfalls "in der Nähe"
gelegenen Newsserver -, werden Postings zwischen den Newsservern
"synchronisiert". In der Regel passiert das mittels des Network News
Transfer Protocol (NNTP). Clients verwenden hysterisch gewachsen
ebenfalls das NNTP mit ein paar Modifikationen.
Inzwischen existieren für den ein oder anderen Internet Mail Access
Protocol Server (IMAP Server) IMAP2NNTP-Gateways, die das von Dir
gewünschte bei Verwendung eines IMAP-Clients leisten können.
Naturgemäß sind IMAP-Clients nicht für den Umgang mit News optimiert,
wodurch der Umgang mit einigen Features der News umständlicher oder
teilweise nicht möglich ist.
> Dennoch speichert offenbar jeder nntp-client die liste der bereits
> gelesenen artikel für sich lokal. Das ist natürlich dann unpraktisch
> wenn man als User X von mehr als einem Client news lesen will. Man kann
> dann eigentlich nur nach dem letzten Lesedatum gehen das man auch erst
> mal präsent haben müsste. Weil Client 2 ja ein anderes haben wird als
> Client 1 an dem man zuletzt las. Eine Zentrale speicherung auf dem
> Server und austausch zum Jew. Client des Users würde das lösen.
denken in zentralen Strukturen.
Seit einiger Zeit existieren DNS-basierte Methoden, Server für
verschiedenste Dienste transparent zu ermitteln / ausfindig zu machen.
Modernere News-Clients dürfen diese Implementieren. Entsprechend würdest
Du (per default) im Urlaub auf einem anderen News-Server lesen (und
potentiell schreiben), als zuhause.
Die Weiterungen bezüglich des Gelesen-Status für Postings kannst Du dir
denken...
> Fragen:
> Gibt es wirklich keinen nntp-server der das zentral pro user notiert?
> Fehlt da evtl. "nur" ein Client/SW diese Info dem Server zu senden?
> Oder umgekehrt ein Client der diese vom Server anfordert?
> Sieht da das nntp-protokoll einfach nichts anderes vor?
Abseits der Verwendung eines IMAP-Server mit IMAP2NNTP-Gateway ist die
Entwicklung eines "Schwester-Protokolls" denkbar, dass den
Gelesen-Status in einem - gegebenenfalls ebenfalls verteilten - System
speichert und in dem man einen entsprechenden Account hat. Das würde
dann das NewsRC-File ersetzen bzw. zu dessen Synchronisierung dienen.
Ein solches Vorgehen hätte sogar noch den Vorteil, dass man über einen
lokal laufenden User-spezifischen Daemon selbst klassische NewsRC-Files
synchronisieren könnte, sodass auch klassische Newsreader mit dem
aktuellen Stand arbeiten würden.
> Kann es sein das dieses Feature einfach nicht mehr wichtig genug ist das
> sich Programmierer mit dessen umsetzung/erweiterung befassen?
mal der Fall war. Entsprechend würde ich davon ausgehen, dass eine
vernünftige Implementierung der von Dir gewünschten Funktionalität
nichts mit "Wichtigkeit" zu tun hat, sondern mit einer unterkritischen
Masse an Entwicklern, die an der Entwicklung und Implemtierung eines
neuen (Hilfs-) Prototolls interesse hätten.
> [...]
Mit freundlichem Gruß,
Henning
--
Can't open /usr/fortunes. Lid stuck on cookie jar.
Peter J. Holzer
Apr 19, 2022, 6:01:32 AM4/19/22
to
On 2022-04-15 16:03, Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Kay Martinen meinte:
>> ... 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?
Ja, natürlich. Wenn ein Client und ein Server miteinander reden sollen,
> Kay Martinen meinte:
>> ... 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?
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).
> Wenn du schon einen lokalen Newsserver benutzt, was hindert dich denn
> dann daran, den .newsrc-Mechanismus zu nutzen? Dass deine Clients den
> nicht benutzem?
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.
> Ach, dann müsstest du doch nur in den Clients mal eben
> was nachimplementieren, nicht auf Client- /und/ Serverseite, wie bei
> deinem Vorschlag.
Client, aber wozu dann das ganze?) und typischerweise haben Clients
keine direkten Kontakt zueinander, du brauchst also erst wieder einen
Server.
hp
Peter J. Holzer
Apr 19, 2022, 6:13:07 AM4/19/22
to
On 2022-04-15 18:14, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Fri, 15 Apr 2022 16:57:39 Kay Martinen wrote:
>> Am 15.04.22 um 14:53 schrieb Stefan Froehlich:
>>> On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
>>>> [...] 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
> On Fri, 15 Apr 2022 16:57:39 Kay Martinen wrote:
>> Am 15.04.22 um 14:53 schrieb Stefan Froehlich:
>>> On Fri, 15 Apr 2022 13:47:45 Thomas Hochstein wrote:
>>>> [...] 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).
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.
> Habe ich gelegentlich bei anderen Dingen schon getan, aber... sorry,
> hier fehlt mir echt jeder Bedarf.
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
Peter J. Holzer
Apr 19, 2022, 6:15:52 AM4/19/22
to
On 2022-04-15 20:10, Thomas Hochstein <t...@thh.name> wrote:
> Stefan Froehlich schrieb:
>> 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
slrn am Handy stelle ich mir eher unpraktisch vor.
> Stefan Froehlich schrieb:
>> 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.
NATs und können nicht direkt miteinander kommunizieren.
Peter J. Holzer
Apr 19, 2022, 6:20:36 AM4/19/22
to
On 2022-04-15 11:47, Thomas Hochstein <t...@thh.name> wrote:
> Kay Martinen schrieb:
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
> Kay Martinen schrieb:
>> 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ß
>
> Nein. Das wäre bei Servern mit zigtausend Newsgroups mit jeweils
> hunderten, vielleicht auch zigtausend Artikeln und zigtausend Nutzern
> nicht praktikabel.
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
Diedrich Ehlerding
Apr 19, 2022, 1:38:51 PM4/19/22
to
Peter J. Holzer meinte:
>>> 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?
lechzen.
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.
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.
> (außer Du hast nur einen
> Client, aber wozu dann das ganze?)
Eben - wozu das Ganze?
> 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.
>>> 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.
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?
>
> 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
> 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).
lechzen.
>
>
>> 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.
Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
>
>> 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.
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.
>
>> 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
>> 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
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.
> (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.
Peter J. Holzer
Apr 22, 2022, 2:28:25 PM4/22/22
to
On 2022-04-19 14:30, Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Peter J. Holzer meinte:
>> 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).
>>> 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.
> 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.
> 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
> Peter J. Holzer meinte:
>>> 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.
>
> Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
> greifen dort hin.
Dazu braucht man einen Fileserver.
>>> 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.
>
> Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
> greifen dort hin.
>> 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.
Client nur sein eigenes .newsrc. Für eine gemeinsame Datenbasis brauchst
Du im Allgemeinen einen Server (reines P2P ist im heutigen Internet eher
schwierig).
>>> 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 ...
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.
> aber wenn du meinst, es sei so trivial, das auf Serverseite zusätzlich
> zu implementieren, dann mach doch.
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.
> Viel Spaß ... und wundere dich nicht, wenn das Interesse für deine
> Erweiterungen übersichtlich bleibt.
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
Apr 22, 2022, 2:51:18 PM4/22/22
to
Peter J. Holzer meinte:
>> Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
>> greifen dort hin.
>
> Dazu braucht man einen Fileserver.
>
>>> 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.
>> Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
>> greifen dort hin.
>
> Dazu braucht man einen Fileserver.
>
>>> 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).
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.
Stefan Froehlich
Apr 23, 2022, 3:07:51 AM4/23/22
to
On Fri, 22 Apr 2022 20:28:23 Peter J. Holzer wrote:
> On 2022-04-19 14:30, Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>> 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
> On 2022-04-19 14:30, Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>> 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.
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.
> Das mangelnde Interesse an der Weiterentwicklung des Usenet hält mich
> seit fast 20 Jahren davon ab, Arbeit zu investieren.
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
(Sloganizer)
Laurenz Trossel
Apr 23, 2022, 3:57:51 AM4/23/22
to
On 2022-04-23, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> 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"?
> 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
bestehender Software führen. Besser wird dafür ein neues Kommando
definiert.
> Immer noch sehr überschaubarer Aufwand, aber dann könnte man mit
> sehr wenig Mühe client-seitig auch komplett auf eine .newsrc
> verzichten.
Stefan Froehlich
Apr 23, 2022, 4:48:17 AM4/23/22
to
On Sat, 23 Apr 2022 09:57:42 Laurenz Trossel wrote:
> On 2022-04-23, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> 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 :-)
> On 2022-04-23, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> 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"?
>> 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.
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
(Sloganizer)
Peter J. Holzer
Apr 23, 2022, 6:15:31 AM4/23/22
to
>>>> du brauchst also erst wieder einen Server.
>>> Nö
>>> 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
Apr 23, 2022, 11:11:10 AM4/23/22
to
Peter J. Holzer meinte:
>>>>> 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
>>>>> 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
bereits einen hat, den er verwenden kann,
Martin Burmester
Apr 27, 2022, 6:55:03 AM4/27/22
to
Hallo,
Am 22.04.2022 um 20:28 schrieb Peter J. Holzer:
> On 2022-04-19 14:30, Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>> Peter J. Holzer meinte:
>>>> 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.
>>
>> Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
>> greifen dort hin.
>
> Dazu braucht man einen Fileserver.
>
>>> 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).
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
Am 22.04.2022 um 20:28 schrieb Peter J. Holzer:
> On 2022-04-19 14:30, Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>> Peter J. Holzer meinte:
>>>> 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.
>>
>> Am einfachsten legt man die .newsrc auf ein Share im Netz, und alle
>> greifen dort hin.
>
> Dazu braucht man einen Fileserver.
>
>>> 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).
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
0 new messages