From: heinau@Harpo.Chemie.FU-Berlin.DE (Vera Heinau)
Subject: Re: Gateway-TUeV (war: Hochgep
Reply-To: admin@methan.chemie.fu-berlin.de
Organization: Free University of Berlin, Germany
Date: Wed, 15 Apr 1992 03:16:39 GMT

Frank.Simon@arbi.informatik.uni-oldenburg.de (Frank 'Terra' Simon) writes:
>urlichs@smurf.sub.org (Matthias Urlichs) writes:
>[...]
>Tjae. Das habe ich mir auch so gedacht. Aber z.B. ich hatte mal eine
>Weile die GateBau-konforme MsgID laufen. Aber zwei Dinge haben mich 
>daran gestoert:
>
>a) Es war nicht vorgesehen, dass ein Artikel gesplittet wird. 

Das ist ja schon ein Punkt, der offensichtlich prinzipiell nicht be-
ruecksichtigt ist - warum eigentlich nicht? Es muss doch eigentlich
klar sein, dass das ein prinzipielles Problem darstellt, was erst geloest
werden muss, *bevor* ein Gateway in Betrieb geht.

>[...]

>>< >Warum haben wir hier die Gruppen "fido.ger.bla" und "fido.bla-ger"? 
>>< Vielleicht warum ihr cl.* und wir comlink.* haben ?  :-)  Sogar das 
>>< hat Gruende. :-) >< 

Fuer alles kann man Gruende finden. Die Frage ist nur, ob sie stichhaltig
sind. Oder ob sie nicht nur die Unfaehigkeit der Gatewaybetreiber zur Kom-
munikation bemaenteln sollen.

>>Vielleicht den Grund, dass die diversen Gatebetreiber ein so aufgeblasenes
>>Ego haben, dass sie es nicht schaffen, sich mal zusammenzusetzen und sich
>>auf einheitliche Formate fuer Groupnamen und IDs zu einigen?
>Du machst es dir zu einfach. 

Hmm, igendwie muss ich Matthias aber zustimmen. Es kann in keinem Fall
sinnvoll sein, die gleichen Newsartikel in unterschiedlichen Hierarchien
einzuspielen.

>Es gab mal eine Weile eine einheitliche
>Newshierachie namens zer.*. Dabei traten Defizite in der GateBau auf, die
>auch nach mehrfacher Kritik UND Korrekturvorschlaegen nicht geaendert
>wurden. Also gab es drei Loesungen:
>a) Mit den Defiziten leben (wollte ich wg. der Benutzer nicht)

Das ist ja wohl keine Loesung, sondern Kapitulation der Gemeinschaft vor
einigen unbelehrbaren Betreibern.

>b) Mit den leuten diskutieren.

    Das ist sicherlich erforderlich, aber ewiges Diskutieren bringt eben
    auch nichts. Irgendwann muessen einfach Naegel mit Koepfen gemacht
    werden.

>c) Also habe ich fuer mich eine Inselloesung geschaffen.

Naja, das mag ja fuer Dich eine Loesung sein (und im Spezialfall sogar
sinnvoll), aber das kann ja nicht als globale Loesung empfohlen werden.

>>< >Mal so gefragt: wenn Du davon nicht begeistert bist, Terra, welche
>>< >Alternativen schlaegst Du denn vor? Den Wildwuchs so weitertreiben
>>< >lassen? Dupes und Chaos ohne Ende? 
>>< Aus dem (kreativen) Chaos erwaechst neue Gedanken und Entwicklungen. 
>>Das ist eine nette Behauptung, die aber nur dann funktioniert, dass sich
>>aus dem Wettbewerb der divergierenden Ideen irgendwannmal eine entwickelt,
>>die als "beste" Idee selektiert wird (nach welchen Kriterien und von wem
>>auch immer), die dann als neuer Standard festgeschrieben wird, damit darauf
>>wieder neue Ideen aufbauen koennen.

Stimmt. Man kann nicht darauf hoffen, dass aus dem Chaos von selbst kon-
struktive Ideen entstehen und sich als Standard durchsetzen.

>Eine TUeV muss mit Testdaten arbeiten. Es gibt paar Dinge (ich erwaehne
>nur das mit der Laenge von Artikeln), die technisch korrekt, aber aus
>bestimmten Gruenden eben doch vereinheitlicht sein muessen. 

Verstehe ich nicht. Was heisst "technisch korrekt, aber vereinheitlicht"?

>Das heisst 
>ein TUeV braeuchte ein Referenzsystem an dem sich alle anderen zu
>orientieren haetten. 

Erstens haette er das mit dem ersten "zugelassenen" Gateway und zweitens
ist das fuer den Start des TUeV nicht unbedingt erforderlich. Etliche
der in der Vergangenheit aufgetretenen *prinzipiellen* Fehler haetten
schon beim Durchlaufen einer "checkliste" bzw. beim Ueberpruefen des
theoretischen Ansatzes gefunden werden koennen.

>>Letzteres ist ein technisches Problem und ich fuer meinen Teil habe keinerlei
>>Lust, dieses mit administrativen Massnahmen beheben zu wollen. Das ist
>>unnoetiger Aufwand, den ich als jemand aufzubringen habe, der an Gate-
>>programmierung und -betrieb an sich Null Interesse hat und der nicht
>>gewillt ist, lokal die von zwei Fido- und drei Comlink-Gates jeweils
>>mehrfach zu halten, nur weil sich die Gates nicht auf ein einheitliches
>>Format einigen koennen.

Meine volle Zustimmung. Wenn ich daran denke, wieviele Mails und Gespraeche
nur deshalb erforderlich sind, weil man eine bestimmte Hierarchie ueber das
Gateway X bezieht und nun sicherstellen soll, dass die Artikel sich nicht
mit denen aus dem Gateway Y mischen. Und jedesmal die Frage, wenn solche
Artikel von einer anderen Site eingespielt werden - sind die nun von dem
"richtigen" Gateway oder nicht?
Soetwas ist eigentlich eine Zumutung fuer alle Sites, die diese Gruppen oder
Hierarchien "nur" transportieren - deren Betreiber haben in der Regel etwas
anderes zu tun, als sich in die Regeln, Besonderheiten und Spezialitaeten
der "Fremd"-Netze zu beschaeftigen.

>[...]
>
>>Ich bin aber nicht gewillt, den administrativen Aufwand in Kauf zu nehmen,
>>von dem 90% durch technische Massnahmen (eben Kompatibilitaet zwischen
>>den Gates -- auf beiden Seiten) vermeidbar sind.
>Das ist die Theorie. Die Praxis zeigt, dass es bei der Theorie bleibt.
>Wenn 5 Leute an 5 Gateways programmieren gemaess GateBau-Spezifikation
>gibt es trotzdem 3-4 Ergebnisse. 

Ja. Und? Solange sie alle Erfordernisse erfuellen - und dazu gehoert eben 
auch (oder gerade), dass sie mit anderen Gateways zusammenarbeiten.

>>< Wir koennen Dupoes nicht vermeiden, weil
>>< a) es unmoeglich ist eine komplexe Software auf richtige Implementation
>><    zu testen, [...]
>>Falsch. Ob zwei Gates dieselbe ID generieren und eine bestimmte Fido-Area 
>Richtig. Hier steht, dass du komplexe Software nicht auf richtige
>Implementierung testen kannst. Das ist Fakt. Mit was willst du das den
>Verfizieren ?  wp-Semantik ? Fixpunktsatz ?  Dann guck nochmal ins
>Script was da zu "Praxisbezug" steht. :-)

Du redest hier aber um das Problem herum. Fakt ist, dass Matthias gar 
nicht verlangt hat, dass die Gatewaysoftware auf prinzipielle hundert-
prozentige Funktionalitaet ueberprueft wird. Fakt ist ferner, dass viele
Leute sich nicht mal um Minimalanforderungen gekuemmert haben - und zumin-
dest soetwas kann ein TUeV schon im Ansatz verhindern.

>>(Bei divergierenden Ansichten ueber Vernunft muessen sich die
>>beteiligten Leute eben solange in ein Zimmer einsperren lassen, bis die
>>Divergenz auf ein vernuenftiges Mass gesunken ist...)
>Wenn du eine perfekte Speizifikation (z.B. auf dem Niveau von RFC's) hast
>und eine perfekte Implementierung (oder sagen wir mal eine 99% perfekte),
>dann hast du recht. 

Hmm, irgendwie habe ich hier das Gefuehl, dass Du sagst, die Programmierer
muesten sich erst dann um Minimalanforderungen kuemmern, wenn andere Leute
100%ig perfekte Spezifikationen erarbeitet haben... nicht unbedingt der
richtige Ansatz, finde ich.
Viel sinnvoller waere es doch, wenn sich ein paar erfahrene Usenetter zu-
sammenfinden wuerden, um zu spezifizieren, welche Bedingungen ein Gateway
ins (deutschsprachige) Usenet erfuellen *muss*, damit es ans Netz gehen
kann. Dass ein solcher Entwurf einer Spezifikation nicht auf Anhieb per-
fekt sein kann, sollte wohl klar sein.

>Nur: Das ist viel Arbeit. Arbeit die sich schon eine Gruppe von Leuten
>     gemacht hat. Arbeit die leider doch zu Problemen vielschichtiger
>     Art gefuehrt hat. Diese Realitaet moege ich nicht uebersehen. :-)

Weder Matthias, Heiko oder einer der anderen hat gesagt, dass soetwas
keine Arbeit bedeuten wuerde. Und alle diese Leute haben genug Praxis-
erfahrung, um entsprechende Probleme nicht zu erkennen. Das heisst aber
nicht zwangslaeufig, dass man nicht versuchen sollte, derartige Probleme
auch mal zu loesen und nicht nur zu bemaengeln oder zu diskutieren.

>     Daher stoert mich das "theoretisieren" ueber einen Gateway-TUeV.
>     Besonders solange, wie sich dafuer niemand freiwillig meldet. :-)

Erstens bin ich der festen Ueberzeugung, dass sich fuer einen vernuenftig
konzipierten Gateway-TUeV auf Usenetseite Leute finden wuerden (wenn ich 
an die viele Arbeit denke, die wir damit haben, fehlgeschlagene Mails
doch noch auf den richtigen Weg zu bringen bzw. Absender und/oder Empfaenger
darueber aufzuklaeren, warum irgendwas schief gelaufen ist, dann koennte
man diese Zeit ruhig in die Arbeit eines solchen TUeVs investieren :-).
Zweitens ist es meiner Meinung nach auch der falsche Weg, zu sagen:
'Also erst will ich wissen, wer die Arbeit macht, und dann mache ich mir
darueber Gedanken, ob eine solche Arbeit ueberhaupt sinnvoll ist.'

>>Auf dem Usenet gibt es auch gelegentliche Dupes durch irgendwelche Software-
>>fehler. Na und? Man sieht die Dupes und die Fehler werden behoben.
>Eben. Im EARN/Bitnet gab es auch manchmal Dupes z.B. in Listservern. Und ?
>Es ist eben das Risiko der Vernetzung, mit solchen sinnlosen Traffic zu
>leben. 

Nein. Dem kann und will ich nicht zustimmen. Du magst Recht haben, dass 
Deine Aeusserung den derzeitigen Zustand beschreibt. Aber in keinem Fall
wuerde ich soetwas als gottgegeben hinnehmen und sagen 'das ist eben so,
das wird immer so sein und deshalb unternehme ich keine Anstrengungen,
das zu aendern'.

>Daher sind mir "Abklemmungsgedanken" oder solche Saetze wie, "Wer
>bis zum 1.4.1992 kein Gatebau-konformes System benutzt, wird abgeklemmt"
>einfach nur suspekt.

Warum? Irgendwann muss man doch zu der Erkenntnis kommen, dass "wilde"
Gateways dem Netzgedanken nur schaden koennen.

>>Form, so dass ich auf dem Subnetz beide in einer Hierarchie fuehren kann und
>>mir nicht jedesmal ueberlegen muss, welcher Satz Gruppen jetzt wo zu finden
>>und ueber welchen Gate zu erreichen ist.
>Der Benutzer soll sich das nicht denken. Klar. Aber der Betreiber. Der
>Betreiber eines Subnet-Systems der znet.* und comlink.* News will, soll
>gefaelligst die wenige Arbeit machen in seinen sys-File und paths-Datei
>vernueftige Eintraege zu machen, damit er die News nicht "ueberall"
>hinspoolt oder sich von ueberallher holt. Das kann er im UseNet machen.
>Wenn er aber maus.*, fido.* und zer.* will, dann geht das eben nicht. 

Stimmt doch gar nicht. Wie willst Du denn sicherstellen, dass Dir keiner
Deiner Feeds ungefragt solche Artikel einspielt, weil er bei sich
eingetragen hat, dass er "alles" zu Dir schickt und ihm ebenfalls irgend-
jemand solche artikel einspielt (und sei es nur als Crossposting).
Das kannst Du nicht. 

>DIESEN Minimalaufwand verlange ich vom Systembetreiber. ER will die
>Informationen aus dem anderen Netz. 

Hmm... und alle Transportsites triffst Du damit auch. Ich sehe es ehrlich
gesagt nicht ein, dass wir uns um den ganzen Hierarchie/Gateway-Kram
mit grossem Zeitaufwand kuemmern muessen, nur weil irgendeine Site hinter
uns diese Gruppen fuehren will. Wobei wir uns diesem Aufwand bisher unter-
werfen, um "unsere" Sites mit den entsprechenden Artikeln versorgen zu
koennen, weil wir das eben als Service auffassen. 
Aber ich wuerde etliches darum geben, wenn wir diesen Service bieten koenn-
ten, ohne uns staendig darum kuemmern zu muessen, von welchem Gateway wel-
che Gruppen kommen, wohin wir sie ohne Probleme weitergeben koennen und 
wohin nicht usw...


Tschuess, Vera

-- 
 |~|    Vera Heinau     (+49 30 8382677)  |  Freie Universitaet Berlin 
 / \    heinau@Harpo.Chemie.FU-Berlin.DE  |  heinau@methan.chemie.fu-berlin.de
/FUB\   Institut fuer Kristallographie    |  Institut fuer Organische Chemie
`---'   D-1000 Berlin 33, Takustr. 6      |  D-1000 Berlin 33, Takustr. 3