AcorNet - the next generation

2. Auflage (28.1.96)
Leicht gekuerzt fuer die Veroeffentlichung

Bestandsaufnahme:
=================


Was bereits erreicht ist
------------------------

Das urspruengliche Konzept von AcorNet war es, moeglichst viele "eigene" Server
einzurichten, die ihre Software gegenseitig mirrorn und einen einheitlichen, komfortablen Zugriff auf die Archive ermoeglichen (per ardt, ftp und WWW).

Mittlerweile ist die zweite, deutlich ueberarbeitete, Version von AcorNet
in Betrieb und hat sich in der Praxis gut bewaehrt, wenn auch bislang in
recht bescheidenem Rahmen (2 Server). (Dieser Entwurf befasst sich mit
der hypothetischen dritten Generation des Netzes!)

Mit Worms und Kaiserslautern (wo seit Anfang Januar mehr Discspace fuer
uns bereitsteht) haben wir jetzt zwei feste Server mit einer Gesamtkapazitaet
von mind. 300 MB. Zwischen beiden Servern soll bald eine Aufteilung der Archive
nach Kategorien erfolgen, um den Platz effizient zu nutzen und die
Maintenance-Arbeit fuer einen Admin zu reduzieren.

Mit der Afa (Archie for Archis)-page steht seit einiger Zeit ein schoenes 
Hilfsmittel zur Verfuegung um Software im Internet zu lokalisieren und runterzuladen.

Zur Kommunikation der Admins und anderer Interessierter untereinander dient uns
eine Mailingliste, die immerhin schon von fuenf (!) Leuten gelesen wird. :)

Wie man aus der Access-Statistik (und immer oefters eigehenden Mails) ersieht, 
erfreut sich AcorNet mittlerweile einer gewissen Bekanntheit. Auf vielen
Pages (neuerdings auch auf den Acorn-Clan-Seiten) sind Links auf unsere Server
und in der Acorn-User war ein genialer Bericht ueber uns, bei dem lediglich
vergessen wurde, unsere Adresse anzugeben! :)))
Einige Software war (zumindest fuer gewisse Zeit :) ausschliesslich bei uns
zu holen. (Xtreme, Coder's Revenge, Connector 0.67b ...)



Ideen fuer eine zukuenftige Neuorganisation
===========================================

Zunaechst sollte es EINEN definierten HAUPTSERVER geben, der die WWW-Seiten
und das ardt-Zeug managt und anderen "Navigationsservern" diese Daten
zusendet. Von diesen untergeordneten Sites sollte sich zumindest eine
in Grossbritannien befinden.

Es gibt also grob gesagt zwei Klassen von Servern: Solche, die tatsaechlich
ARCHIVE zum Downloaden bereitstellen und andere, die lediglich ein Interface
zum Zugriff bieten. Natuerlich braucht diese Trennung nicht strikt zu sein:
Bei genuegender Bandbreite kann ja auch ein Navigationsserver eigene Software
lagern. Allerdings sollten die beiden Beriche dann moeglichst klar voneinander
abgegrenzt sein um die Sache nicht komplizierter als noetig zu machen.

Wie soll das nun in der Praxis aussehen?
Ich will mal versuchen das in Form von vier typischen Szenarien zu schildern:


Situation: Jemand will ein bestimmtes Programm suchen und downloaden

Der besagte User kontaktet eine Navigations-URL von AcorNet (oder nimmt ardt hierfuer) und erhaelt eine wunderschoene Seite, die ihm eine Titelsuche
anbietet. Wenn man Glueck hat spuckt die Search Engine das Gewuenschte aus;
unter Umstaenden sogar mehrmals, wenn die Software auf verschiedenen Servern
zu haben ist.
Man kann nun entweder auf die short-description klicken und zusaetzliche
Informationen zu dem betreffenden Archiv anfordern, oder den Programmnamen
direkt anwaehlen und bekommt daraufhin das Programm vom Server seiner Wahl
geschickt.
(Ein Navigationsserver uebernimmt also die Aufgaben der momentanen Afa-Page!)


Situation: Ein Benutzer will nachsehen, was so an neuem Stoff im Netz ist

Hierfuer sind natuerlich die Recent-Indices des Hauptservers praedestiniert,
die eine Uebersicht ueber die Uploads der letzten 7/14/28 Tage bieten.
Sollte es mal zu einer akuten Softwareschwemme kommen (man darf die
Hoffung ja nie aufgeben :) koennen diese zusammengefassten Zeitraeume
ja jederzeit verfeinert werden.


Situation: Jemand will wissen, welche Silly-Progs es fuer den Archi gibt

Was liegt also naeher als sich den Filetree von AcorNet anzusehen, nach
fun/silly_progs zu gehen und voila...
Man hat nun alles auf einen Blick und muss nicht auf den verschiedensten
Servern recherchieren!


Situation: Jemand will eine bestimmte (umfangreiche) Software uebers Netz verteilen, ohne sie auf einen anderen Server laden zu muessen

Dazu schickt man eine kurze Mail an den Hauptserver von AcorNet und gibt an, was
man gerne anbieten moechte. Man erhaelt dann ein kurzes und einfach zu
bedienendes Skript geschickt und geht folgendermassen vor:

Man benoetigt nur einen Rechner, auf dem anonymous ftp oder WWW-Access
moeglich ist. Dann richtet man ein Verzeichnis ein
mit AcorNet-konformem Namen (dazu mehr unten), tut seine Software rein und 
macht auch die vorgeschriebenen, standardisierten .txt-Files (wie wir sie schon
kennen).
Dann startet man das Skript, das feststellt, welche Files wo liegen und eine
diesbezuegliche Mail an den Hauptserver schickt (sowas macht dass mr.pl ja jetzt
schon mit sigas Afa-Page) und den short-tree erzeugt. Fertig!

Im Hauptserver passiert nun folgendes durch einen automatisierten Prozess:
Zunaechst werden aus der Gesamtliste alle Eintraege geloescht, die von der
mailenden Site evtl. schon bekannt sind (weil es ja durchaus sein kann
dass Files geloescht wurden :) und danach werden die neuen Daten
in die entsprechenden Listen (short/longnametree, thematisch geordnetes
Verzeichnis, !NFS-Tree (?) etc.) eingebaut. Damit ist ein sofortiger Zugriff auf die neuen Sachen moeglich!

Sinn machen wuerde das natuerlich vor allem bei Mega-Programmen wie RiscBSD, die
staendig aktualisiert werden und die man nicht gerne komplett jedesmal auf den
eigenen Server zieht. Ausserdem koennte diese einfache Art, eigene Software
ohne grossse Muehe einer grossen Zahl von Leuten anzubieten, viele Leute
dazu bewegen, ihre Programme ins AcorNet einzugliedern.
Damit wiederum stiegen unsere Chancen, einen "Standard" zu setzen.



Folgendes ist vielleicht noch zu beachten:

- Wie berechtigterweise angemerkt wurde, ist es wohl etwas uebertrieben,
  von jedem Softwarebereitsteller zu verlangen, das Skript zu benutzen.
  Einigen ist es bestimmt auch nicht ohne groesseren Aufwand moeglich,
  PERL aufzutreiben. Deshalb sollte auf jeden Fall eine Moeglichkeit
  bestehen, durch einfache Angabe seiner Software an den HAUPTSERVER
  einen Listeneintrag zu erwirken (nach Ueberpruefung der Daten).
  Worms, Kaiserslautern und aehnliche Server arbeiten natuerlich zweckmaessig
  weiterhin mit den Skripten (grosser Datenbestand)!

- Die Pflege der WWW-Seiten obliegt in diesem Konzept nur EINER Person (oder
  einem Team oder oder...) Insofern muss sich sonst niemand um die Admin-
  Aufgaben, die damit zusammenhaengen, kuemmern und kann sich auf die Pflege
  seiner Datenpfade konzentrieren.
  (Die lokalen Admins brauchen ja nicht mal mehr das umfangreiche
  mr zu besitzen. Wenn man nur wenige Archive anbieten will, kommt man
  sogar gaenzlich um die Skripte herum --> siehe weiter unten...)
  Erweiterungen des Services etc. sind somit auch einfacher moeglich als wenn
  jeder die Seiten bei seinem lokalen Server anpassen muesste.
  Es koennte sich ja vielleicht sogar "im Schatten" des AcorNet so etwas
  entwickeln wie das Acorn Cybervillage mit Sammlungen von Links und anderen
  interessanten (auch kommerziellen?) Informationen auf den Seiten.
  Was waere z.B. mit Angebotslisten deutscher Haendler?

- Dadurch, dass die Archive auf viele Server verteilt sind, ergaebe sich
  auch die Moeglichkeit, Dinge einzubinden wie Sammlungen von Soundmodulen
  oder Replay-Filmen etc., wofuer wir momentan einfach keinen Platz haben.
  Gerade das koennte aber unserem Anspruch auf "vollstaendiger Abdeckung
  aller Acorn-relevanter Dinge" leicht Abbruch tun. :)
  Natuerlich darf es nicht passieren, dass die Binaries irgendwann alles
  andere ersticken. Allerdings gibt es wohl in der Acornwelt nicht diese
  Masse an Datenfiles wie im Aminet, und zumindest bei WWW-Zugriff sollte
  man diese Sachen entsprechend gut und uebersichtlich einordnen koennen.
  Beispielsweise durch Pfadnamen wie graphics/data/jpegs/pornos :)))

- Durch die "Zusammenlagerung" verschiedenster Softwarequellen werden sicher
  oft "Ueberschneidungen" vorkommen, d.h. dass die gleichen Programme auf
  mehreren Servern vorhanden sind. Das muss aber nicht unbedingt schlimm
  sein: Der Downloader sieht z.B. (wenn die Files alphabetisch sortiert sind)
  mehrere Eintraege "Xtreme.arc" untereinander stehen und kann sich dann
  ueberlegen, von welchem Server er die Daten am schnellsten kriegt.
  Insofern ist es nach wie vor sinnvoll, Soft aus England zu mirrorn,
  weil sie so den deutschen Benutzern leichter zugaenglich ist und die
  Netzlast reduziert.

- Das Konzept von Vezeichnisbaeumen halte ich weiterhin fuer gut! Einerseits
  ergibt sich daraus ja automatisch der Zwang zum thematischen Einordnen,
  andererseits koennen die hartgesottenen ftp-Freaks weiterhin gut auf
  AcorNet-Servern rumsuchen.

- Es ist darauf hingewiesen worden, dass die Gefahr besteht, AcorNet
  extrem und einseitig auf WWW auszulegen.
  Rein persoenlich kann ich das nicht ganz nachvollziehen: AcorNet ist ja
  prinzipiell aufs Internet zugeschnitten, welches in Zukunft immer mehr
  Menschen zur Verfuegung stehen wird, nicht zuletzt auch durch endlich
  verfuegbare gute Internet-Pakete fuer Acornrechner und vielleicht
  irgendwann durch diese ominoese Netsurfer-Box von Acorn&Oracle... :))
  Damit wird sicher auch der WWW-Access immer bedeutender werden. Ich kann
  mir nicht vorstellen dass in Zukunft noch viele Leute per ftp direkt
  Software ziehen wollen (obgleich das ja bei uns moeglich ist!!!).
  ardt ist eine guter und bequemer "Mittelweg" und soll ja auch in Zukunft
  unterstuetzt werden. Dies duerfte kein Problem sein, wenn man das jetzige
  mr als Ausgangspunkt fuer das Hauptserverskript nutzt.
  Neue Files (und zwar aufs ganze AcorNet bezogen!) werden auch in den
  Recent-pages aufgefuehrt und somit sollte der WWW-Zugriff keinen Nachteil
  haben - bezogen auf ardt.

- Ein Downloadtool (a la ardt) fuer den WIMP des Archis waere nach wie vor eine
  wuenschenswerte Sache. Wer kennt jemanden mit den entsprechenden Kenntnissen
  und genug Freizeit? :)
  Neulich war der Autor des gleichnamigen Internetpakets (!Acornet) im IRC. Er
  koennte es leicht einrichten, dass man per einfachem Mausklick in unser
  AcorNet eingelinkt wird. So etwas sollte man sich evtl. auch mal ueberlegen
  und den Autoren von einschlaegiger Software die Nase auf uns stossen. :)
  


Ideen zur praktische Umsetzung:
-------------------------------

Mit den vorhandenen AcorNet-Servern ist ja schon eine gute Ausgangsbasis
vorhanden, sprich: Softwaresammlungen, die unseren Vostellungen gemaess
sortiert sind und mit .txt-Files ausgestattet sind.
(BTW: Man sollte vielleicht die Gelegenheit nutzen und die Verwendung
dieser Files verbindlich vorschreiben. Dann kaeme man auch um den Umstand
mit den .filemaps herum. Notfalls erzeugt man halt manuell oder so zu jedem
File zu dem der .txt fehlt einen mit den notduerftigsten Angaben.)

In einem ersten Schritt koennte man sich (ausgehend von der existierenden
.dirmap) einen STANDARDISIERTEN Verzeichnisbaum definieren, an den sich jeder
halten muss.
Heisst also: Wenn jemand ein Soundtool geschrieben hat, soll er es gefaelligst
in einen Pfad sound/apps oder so stecken. Bei Bedarf kann man natuerlich jederzeit neue "Aeste" im Verzeichnisbaum einrichten. Wichtig ist nur, dass
das koordiniert erfolgt und sich die Leute dran halten. (Die entsprechenden
Infos muessen also auf dem Hauptserver einsehbar sein).

Wichtig ist das deshalb, damit das Hauptserver-Skript neue Files sinnvoll
ins bestehende Schema uebernehmen kann (fuer die Suche nach Themengebieten).
Wenn also z.B. irgendjemand irgendwo sein Skript laufen laesst und bei uns
eine Mail eintrifft mit nicht-konformen (d.h. unbekannten) Pfadnamen, so
sollte sich das Hauptserverskript weigern, diese Sachen einzusortieren.

(Eine Alternatividee ist hier die Verwendung von genormten Keywords
in den .txt-Files anstelle von vorgeschriebenen Directorynamen.
Allerdings muesste man dann jede Menge bestehender .txte anpassen -
und das klingt verdammt nach Arbeit... :)

Es sollte klargeworden sein, dass im Rahmen dieses Konzepts keine "Riesenserver"
noetig sind, die viel Software halten. Demnach entfaellt wohl auch der Bedarf
an einem geschwindigkeitsoptimierten Skript.


Natuerlich braeuchten wir aber zwei "neue" Skripte:

1. Fuer die lokalen Admins eine abgespeckte Version des mr, die nur noch
das Wesentliche macht und ganz einfach zu bedienen sein sollte weil man
nichtmal mehr irgendwelche Pfade voreinstellen muss. (WWW- und ardt-File-
Erstellung entfallen vollstaendig, desgleichen auch die Recent-Index-Erstellung
und das hantieren mit .dirmap und .filemap). Man koennte es z.B. so machen, dass
das Skript in der obersten Fileebene liegt und alles managt, was darunter liegt.

Kleine Sites brachen nichtmal dieses Skript, sondern koennen ihre Software
"per Hand" beim Hauptserver anmelden. Dazu waere ein kombiniertes System aus
Email und HTML-Forms erwaegenswert.


2. Die restlichen Aufgaben muss das Hauptserver-Skript machen. Dazu gehoeren
die Erzeugung der WWW-Seiten und ardt-Files, ausserdem die Erstellung der
Recent-Indices (die sich jetzt auf das GESAMTE Netz beziehen!).
Dieses Skript hat dann demnach sehr viele Daten zu managen, allerdings
nur in Form von Anpassungen diverser Listen und nicht durch "Abgrasen"
von Verzeichnisbaeumen. Geht man also davon aus, dass der Hauptserver
keine eigene Software enthaelt, sollte sich auch dieses Skript durch Verwendung
von Routinen aus mr erzeugen lassen und nicht allzu geschwindigkeitskritisch sein.

Ich kann schlecht abschaetzen wie leicht oder schwer das Konzept
programmiertechnisch umzusetzen waere und finde es sowieso recht erstaunlich,
dass die automatische Verwaltung der Afa-Page so gut funktioniert... :)
Ermutigend ist aber auf jeden Fall, dass sich Peter in Bezug auf die
technische Machbarkeit so optimistisch geaeussert hat!


Natuerlich gaebe es - abgesehen von technischen Schwierigkeiten - sicherlich 
auch andere moegliche Problemfelder: Wo viele Leute reinpfuschen kann auch
Einiges ausser Kontrolle geraten.

Was macht man z.B. mit Leuten, die kommerzielle Soft oder andere
unanstaendige Sachen einbinden wollen? Es muss demnach eine Moeglichkeit
geben, unerwuenschte "Softwareanbieter" gegebenenfalls auszuschliessen.

Auch koennte es vorkommen dass Leute ihre Archive loeschen ohne das dem
Hauptserver zu melden. Als Ergebnis hat man dann jede Menge Karteileichen
im System.

Es ist also ein Mindestmass an Intelligenz und Verantwortung der Teilnehmer
vorauszusetzen.


Vermutlich laeuft es dann so, dass Acorn ausgerechnet in dem Moment
pleite geht, in dem die Usergemeinde ein vorbildliches Netz zur
Softwareverteilung aufgebaut hat.... Naja, ich will den Teufel ja nicht
ans Pinboard malen... :)))

Bitte meldet Euch bei uns wenn Ihr weitere Ideen habt oder Euch an der Entwicklung von AcorNet beteiligen wollt!