Verkettung und Baum-Ansicht (was: tt oxp)

[Marcel Logen]

Dennis Preiser in de.alt.test:

>Marcel Logen <33320000...@ybtra.de> wrote:
>> Marcel Logen in de.alt.test:

>>>Ja, daß auch mal Message-IDs fehlen können, hatte ich nicht bedacht.
>>
>> Wenn man die Verkettung allerdings nur mit dem jeweils letzten Refe-
>> rences-Eintrag macht, sollte es aber doch eigentlich kein Problem geben.
>> Grübel.
>
>Und wenn der Artikel des letzten References-Eintrag gecancelt wurde?

Das ist dann Pech, würde ich sagen. Da fängt dann eben wieder ein
neuer Thread an.

In diesem Fall eine Verkettung mit dem vorletzten References-Eintrag
vorzunehmen, führt IMHO eh zu Verwirrung, da das Posting ja keine di-
rekte Antwort auf diesen vorletzten Artikel ist.

Marcel 1ohuu (1853406)

Ich fuppe mal nach "newsreader".
--
──╮ ╭──────╮ ╭─────╮ ╭─╮ ╭─╮ ╭───────
│ ╭───────╮ ╰───╮ │ ╭─╯ ╭─╮ ╰──╮ ╭─╮ ╭──╯ │ ╭─╯ ╰──╮ ╰─────╮
╰───╯ ╭────╯ ╭────╯ │ ╰───╯ ╰─╮ ╰─╮ │ ╰─╯ ╭─╯ ╰───╮ │ ╭────╯
╰──────╯ ╰──────────╯ ╰─╯ ╰────────╯ ╰───╯226b45

[Michael Bäuerle]

Dennis Preiser wrote:

> In de.alt.test Marcel Logen <33320000...@ybtra.de> wrote:
> > Dennis Preiser in de.alt.test:
> > > Marcel Logen <33320000...@ybtra.de> wrote:
> > > >
> > > > Wenn man die Verkettung allerdings nur mit dem jeweils letzten Refe-
> > > > rences-Eintrag macht, sollte es aber doch eigentlich kein Problem geben.
> > > > Grübel.
> > >
> > > Und wenn der Artikel des letzten References-Eintrag gecancelt wurde?
> >
> > Das ist dann Pech, würde ich sagen. Da fängt dann eben wieder ein
> > neuer Thread an.
>

> Das würde mir nicht gefällen.

Mir auch nicht.

> > In diesem Fall eine Verkettung mit dem vorletzten References-Eintrag
> > vorzunehmen, führt IMHO eh zu Verwirrung, da das Posting ja keine di-
> > rekte Antwort auf diesen vorletzten Artikel ist.
>

> Ein grafischer Newsreader könnte die nicht mehr vorhandenen Artikel
> ausgegraut darstellen, wie es z. B. MacSoup gemacht hat:
>
> <http://www.fen-net.de/mac/bilder/macsoup/Thread.gif>

Für flnews 2.x wäre meine Vorstellung etwa so:
Der Thread sollte so vollständig wie möglich angezeigt werden, d.h
jeder bekannten Message-ID in den References sollte ein Node in der
Darstellung entsprechen.
Wenn ein Artikel nicht zugänglich ist, z.B. weil er nicht geladen, oder
gecancelt wurde, könnte da "Missing" stehen.
Wenn in einem Ast eine Lücke mit unbekannter Größe existiert, die
Zuordnung zum Thread durch die erste Message-ID in den References
(die nicht getrimt werden darf) aber möglich ist, könnte da "Gap"
stehen. So ein Node würde dann mehrere Artikel repräsentieren.
Für ersetzte Artikel wird aktuell bereits "Superseded" verwendet.
Für einen via Scoring entfernten Artikel könnte da "Killed" stehen.

[Marcel Logen]

Michael Bäuerle in de.comm.software.newsreader:

>Dennis Preiser wrote:
>> In de.alt.test Marcel Logen <33320000...@ybtra.de> wrote:

[...]

>> > In diesem Fall eine Verkettung mit dem vorletzten References-Eintrag
>> > vorzunehmen, führt IMHO eh zu Verwirrung, da das Posting ja keine di-
>> > rekte Antwort auf diesen vorletzten Artikel ist.
>>
>> Ein grafischer Newsreader könnte die nicht mehr vorhandenen Artikel
>> ausgegraut darstellen, wie es z. B. MacSoup gemacht hat:
>>
>> <http://www.fen-net.de/mac/bilder/macsoup/Thread.gif>
>
>Für flnews 2.x wäre meine Vorstellung etwa so:
>Der Thread sollte so vollständig wie möglich angezeigt werden, d.h
>jeder bekannten Message-ID in den References sollte ein Node in der
>Darstellung entsprechen.
>Wenn ein Artikel nicht zugänglich ist, z.B. weil er nicht geladen, oder
>gecancelt wurde, könnte da "Missing" stehen.
>Wenn in einem Ast eine Lücke mit unbekannter Größe existiert, die
>Zuordnung zum Thread durch die erste Message-ID in den References
>(die nicht getrimt werden darf) aber möglich ist, könnte da "Gap"
>stehen. So ein Node würde dann mehrere Artikel repräsentieren.
>Für ersetzte Artikel wird aktuell bereits "Superseded" verwendet.
>Für einen via Scoring entfernten Artikel könnte da "Killed" stehen.

Wäre das nicht schwierig zu implementieren?

Man müßte ja dann eigentlich von jedem Posting im Thread jeden
References-Eintrag auswerten, oder nicht? Und das Ganze dann auch
noch irgendwie 'synchronisieren' bzw. unter einen Hut bringen ...

Das stelle ich mir nicht einfach vor.

Marcel 1sj01 (1985537)
--
───╮ ╭───╮ ╭──╮ ╭─╮ ╭───────────╮
╭─╯ ╭────╮ ╰─╮ ╰─╯ ╰─╮ │ ╰─╮ ╰────────╮ ╰─╮
╰──╮ ╭──╯ ╭─╯ ╭─╯ ╭─────╯ ╭─────╯ ╰──╮ ╭────╯ ╭─╯ ╭─────╮
╰───╯ ╰────╯ ╰─────────╯ ╰───╯ fa74f3╰───╯ ╰──

[Michael Bäuerle]

Das wird ja bereits gemacht (und ggf. für jeden der gesamte Baum
durchsucht).

> Und das Ganze dann auch
> noch irgendwie 'synchronisieren' bzw. unter einen Hut bringen ...
> Das stelle ich mir nicht einfach vor.

Es fehlt hauptsächlich die Unterstützung für die Umstrukturierung des
Baums. Aktuell wird ein einmal in die Hierarchie eingebauter Artikel
nicht mehr verschoben und Lücken werden nicht unterstützt (das führt
beim einfügen in falscher Reihenfolge zum falschen Ergebnis).

Eine Möglichkeit wäre noch, die Zuordnung zum Thread nur an der ersten
Referenz festzumachen (die nicht getrimmt werden darf [1]). Damit würde
sich die Suche nach dem Elternartikel nur auf diesen Ast des Baums
beschränken.
Der Artikel wird dann in den richtigen Ast einsortiert, auch wenn keiner
der referenzierten Artikel gefunden wurde:

Root - Missing - Gap - [*hier*]
^^^^^^^
Diesen hier separat als Anker des Threads, er bekommt die Message-ID
der ersten Referenz (für die Zuordnung weiterer Artikel und damit sich
verschiedene Threads im Fl_Tree-Widget des GUI separat anzeigen und
verbergen lassen).

"Gap" bekommt keine Message-ID, weil ein solcher Node für mehrere
Artikel steht.


___________
[1] <https://www.rfc-editor.org/rfc/rfc5537.html#section-3.4.4>

[Henning Hucke]

In de.comm.software.newsreader Marcel Logen <33320000...@ybtra.de> wrote:

Hallo Marcel,

> [...]

>>Und wenn der Artikel des letzten References-Eintrag gecancelt wurde?
>
> Das ist dann Pech, würde ich sagen. Da fängt dann eben wieder ein
> neuer Thread an.
>
> In diesem Fall eine Verkettung mit dem vorletzten References-Eintrag
> vorzunehmen, führt IMHO eh zu Verwirrung, da das Posting ja keine di-
> rekte Antwort auf diesen vorletzten Artikel ist.

Sachargument:
Aus diesem Grund ist vernüftiges Zitieren, bedachtes Interpretieren und
zurückhaltendes Reagieren sinnvoll.
Aber NetNews waren bereits 2000 ein "altes" Medium (Über 20 Jahre. Und
bekanntlich ist Mail erst recht bereits ein altes Medium (nicht in
Relation zu Papierbriefen aber in Relation zu einem Menschenleben)).
Entsprechend war bereits Zeit gewesen, einige Sachen durchzuspielen und
deren Sinnhaftigkeit konnte sich beweisen.
Eine sinnvolle Sache ist der References-Header, die Verwendung "einiger"
MessageIds in diesem in bestimmter Reihenfolge *und* Verkettung trotz
fehlender referenzierter Postings.

Emotionales Argument:
Es wird nach mehr als vierzig Jahren Netnews so getan, als wären die
Entwickler der Formate und Protokolle nicht in der Lage gewesen, sich
sinnvolle Gedanken zu machen und als hätten sie sich in der täglichen
- bis in die 2000er hinein reichenden - Anwendung über Anpassungen und
Änderungen keine Gedanken gemacht.
Da sind im Jahr mindestens einmal Threads los gegangen, ob der ein oder
andere Header, der ein oder andere Protokollteil sinnvoll ist.

Aber:
Das Verketten passiert - in diesem Fall Gott sei Dank - im Client,
weshalb es legitim ist, dass im Client geeignet konfigirierbar zu
machen (aber bitte nicht in der Bestückung der References-Header als
solcher!).
Wenn also jemand einen neuen/entkoppelten Thread *angezeigt* bekommen
möchte, wenn ein referenziertes Posting fehlt, dann mag er das gerne so
konfigurieren. Beu neueren Client kannst Du das gerne veranlassen, bei
"alten" kannst Du gerne die Entwickler, so weit noch vorhanden und
aktiv, davon überzaugen, entsprechendes einzubauen oder auch gerne Hand
anlegen und einen entsprechenden Fork bauen. Die Zeit wird zeigen, ob
Deine Gedanken genügend geteilt werden...

MfG Henning
--
"nobody is perfect."
-- Nobody ;)

[Marcel Logen]

Henning Hucke in de.comm.software.newsreader:

[...]

>Aber:
>Das Verketten passiert - in diesem Fall Gott sei Dank - im Client,
>weshalb es legitim ist, dass im Client geeignet konfigirierbar zu
>machen (aber bitte nicht in der Bestückung der References-Header als
>solcher!).

ACK

Danke für Deine Überlegungen.

Was mich selbst angeht: Ich lese meistens nicht in Thread-Darstel-
lung, sondern nach Eingangsreihenfolge der Postings. Die Baum-An-
sicht schalte ich nur selten einmal ein.

Ich hatte mir nur allgemeine Gedanken darüber gemacht, wie man
eine sinnvolle Thread-Darstellung basierend auf den References
hinbekommen könnte - unter der Voraussetzung von Dennis, daß auch
mal Artikel fehlen können. Oder dem Hinweis von Thomas, daß sich
das Subject ändern kann.

Das scheint mir jedenfalls keine leichte Aufgabe zu sein.

Marcel 1rlhb (1955371)
--
╭────╮ ╭─╮ ╭─╮ ╭───╮ ╭─╯
╭─────╮ │ ╰────╮ ╭──╯ │ │ │ ╭─╮ ╰─╮ ╰───╮ ╭────╯
│ ╭──╯ ╭─╯ ╭──╯ ╰─╮ ╰─╮ ╭─╯ │ ╭─╯ │ ╭─╯ ╭──╯ ╭──╮ │
─╯ ╰────╯ ╰───────╯ ╰─╯ ╰─╯ ╰──╯ ╰──────╯ ╰──╯ 4d1506

[Michael Bäuerle]

Dennis Preiser wrote:
> Michael Bäuerle <michael....@stz-e.de> wrote:

> > Dennis Preiser wrote:
> > >
> > > Ein grafischer Newsreader könnte die nicht mehr vorhandenen Artikel
> > > ausgegraut darstellen, wie es z. B. MacSoup gemacht hat:
> > >
> > > <http://www.fen-net.de/mac/bilder/macsoup/Thread.gif>
> >
> > Für flnews 2.x wäre meine Vorstellung etwa so:
> > Der Thread sollte so vollständig wie möglich angezeigt werden, d.h
> > jeder bekannten Message-ID in den References sollte ein Node in der
> > Darstellung entsprechen.
> > Wenn ein Artikel nicht zugänglich ist, z.B. weil er nicht geladen, oder
> > gecancelt wurde, könnte da "Missing" stehen.
>

> Das wäre optimal.

>
> > Wenn in einem Ast eine Lücke mit unbekannter Größe existiert, die
> > Zuordnung zum Thread durch die erste Message-ID in den References
> > (die nicht getrimt werden darf) aber möglich ist, könnte da "Gap"
> > stehen. So ein Node würde dann mehrere Artikel repräsentieren.
>

> Meiner Meinung nach wäre es wichtig, konsistent zu der klickbaren
> References:-Zeile zu sein. Ich hab gerade in de.test vier Artikel mit
> Subject "R1" gepostet und den ersten dann gecancelt. Der zweite startet
> jetzt den Thread und hat diese References:-Zeile:
>
> | References: [0]
>
> Die '0' ist klickbar, es wird allerding "Article not found" angezeigt.

Ja,für den Artikel <news:0Ti95bg6I286pNfm%25de...@coredump.d--p.de>.
(Message-ID <0Ti95bg6I286pNfm%den...@coredump.d--p.de>)

Die klickbare Liste wird aus dem Header des angezeigten Artikels
erzeugt. Sie hat also momentan nicht direkt etwas mit dem angezeigten
Baum zu tun, der aus den tatsächlich vorhandenen Artikeln erzeugt wird.

> Der Link könnte dann auf den pseudo-Node mit "Missing" springen.

Das hört sich sinnvoll an.

[Henning Hucke]

Marcel Logen <33320000...@ybtra.de> wrote:

Hallo Marcel,

> [...]

> Ich hatte mir nur allgemeine Gedanken darüber gemacht, wie man
> eine sinnvolle Thread-Darstellung basierend auf den References
> hinbekommen könnte - unter der Voraussetzung von Dennis, daß auch
> mal Artikel fehlen können. Oder dem Hinweis von Thomas, daß sich
> das Subject ändern kann.
>
> Das scheint mir jedenfalls keine leichte Aufgabe zu sein.

jein. Das beste, was mir bisher als Gedanke untergekommen ist, ist
tatsächlich der References-Header. Unter anderem, weil er sich auf das
bezieht, was ein Posting einzigartige identifiziert, die Message-Id.

Es ist in Ordnung, sich hin und wieder etwas besseres zu überlegen zu
versuchen aber manches könnte man auch sehr schnell als untauglich
identifizieren; zum Beispiel das Subject. Im Zweifelsfall verwendet
jemand böswilliger Weise das selbe Subject (Ich schliesse mit dieser
Aussage (bewusst) Spielarten wie mit einem Salt/Thread-Startdatum
gehashte Subjects mit ein) und bekommt dadurch eine "Verkettung" mit
einem Thread hin, zu dem dieser gar nicht gehört (Ja, mann kan natürlich
auch einfach auf ein entsprechendes Posting antworten und bekommt es
auch mit References hin. Es geht mir um "andere" Methoden)).

Ich weiß nicht, was Microsoft sich mal mit seinem Thread-Index überlegt
hatte. Ich weiss aber, dass das nicht funktioniert, sie es aber auch
nicht wieder raus werfen.

MfG Henning
--
BOFH excuse #234:
Someone is broadcasting pygmy packets and the router doesn't know how
to deal with them.

[Marcel Logen]

Henning Hucke in de.comm.software.newsreader:

>Marcel Logen <33320000...@ybtra.de> wrote:

>> Ich hatte mir nur allgemeine Gedanken darüber gemacht, wie man
>> eine sinnvolle Thread-Darstellung basierend auf den References
>> hinbekommen könnte - unter der Voraussetzung von Dennis, daß auch
>> mal Artikel fehlen können. Oder dem Hinweis von Thomas, daß sich
>> das Subject ändern kann.
>>
>> Das scheint mir jedenfalls keine leichte Aufgabe zu sein.
>
>jein. Das beste, was mir bisher als Gedanke untergekommen ist, ist
>tatsächlich der References-Header. Unter anderem, weil er sich auf das
>bezieht, was ein Posting einzigartige identifiziert, die Message-Id.

Das ist schon richtig, aber es können - wie im Thread schon gesagt
- auch einzelne oder mehrere Artikel fehlen. Wie bekommt man dann
die Baum-Darstellung hin? (Dazu haben Michael und Dennis ja schon
etwas gesagt.)

>Es ist in Ordnung, sich hin und wieder etwas besseres zu überlegen zu
>versuchen aber manches könnte man auch sehr schnell als untauglich
>identifizieren; zum Beispiel das Subject. Im Zweifelsfall verwendet
>jemand böswilliger Weise das selbe Subject (Ich schliesse mit dieser
>Aussage (bewusst) Spielarten wie mit einem Salt/Thread-Startdatum
>gehashte Subjects mit ein) und bekommt dadurch eine "Verkettung" mit

Solche Subjects kenne ich nur aus alt.anonymous.messages.

Aber man könnte natürlich auch Newsreader-intern mit so etwas
arbeiten. Erscheint mir aber angesichts verschiedener Möglich-
keiten der Kodierung von Text (Normalisierung erforderlich, z. B.
Unicode/NFC) und der eventuellen Faltung des Subjects auch eher
aufwendig zu sein.

[...]

>Ich weiß nicht, was Microsoft sich mal mit seinem Thread-Index überlegt
>hatte. Ich weiss aber, dass das nicht funktioniert, sie es aber auch
>nicht wieder raus werfen.

"Thread-Index" habe ich bisher IIRC nur bei Mail gesehen, nicht
bei News.

Marcel 3trq (128890)
--
─╮ ╭──╮ ╭───╮ ╭───╮ ╭─╮ ╭─
│ ╭───╮ ╭───╯ ╰─╮ ╭──╮ ╰─╮ ╰────╯ ╰────╯ │ │
╰─╯ ╰───╯ ╰─╯ ╰─╮ ╭─╮ ╰──────────╮ ╭───╯ ╭──╮ │
a45bf8 ╰───────────╯ ╰─────────────╯ ╰─────╯ ╰──╯