[Allegro] Hosting von allegro-Datenbanken

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Koehn, liebe Liste,

> I D E E
> 
> Idee 1
> 
> Da viele Web-Hoster schon günstige Lösungen mit MySQL und PHP anbieten, die  
> allegro-Datenbank in eine SQL-Datenbank zu bringen, vielleicht mittels aresqa : 
> allegro relational. 
> 
> Gibt es bereits Erfahrungen?

Konkrete Erfahrungen nicht. Das laeuft allerdings darauf hinaus, die
relationale Struktur fuer ein Bibliothekssystem zu erfinden und danach
eines zu entwickeln. Aresqa wird da wenig helfen.


> Idee 2
> 
> Ich miete mir einen eigenen Server und biete das Hosting zum Selbstkostenpreis an 
> und hoffe auf viele ähnliche allegro-Inseln, damit sich die Kosten tragen und für 
> die einzelen günstig sind.
> 
> Oder es findet sich ein Verbund der allegro-Inseln.

Frueher - als wir alle etwas weniger weise waren - war der Konsens,
dass allegro-Anwender stets in der Lage sind, andere allegro-Anwender
zu finden, die ihnen behilflich sein koennen. Denn gerade bei Avanti
ist es ja so, dass er wenig Netzwerkresourcen verbraucht, und wer
Avanti aufgesetzt hat, kann damit ohne Probleme weitere Datenbanken
zugaenglich machen.

Diese Beobachtung ist auch heute noch wahr, eine weitere Datenbank unter
avanti zugaenglich zu machen ist m.E. sogar eine der ganz wenigen Dinge,
die bei allegro wirklich einfach sind. Trotzdem hat gerade bei Avanti
diese Art der Nachbarschaftshilfe nie richtig funktioniert.

Gruende dafuer koennten folgende sein:
- - Einen Avanti-Server "in Produktion" betreut meist nicht (mehr) die
  Bibliothek selber, sondern die EDV-Abteilung, meinetwegen auch die
  dedizierte EDV-Abteilung der Bibliothek. Deswegen (weil stets
  mehrere Abteilungen involviert sind) geht es fast nirgendwo auf dem
  "kleinen Dienstweg" sondern so eine Kooperation ist ploetzlich
  eine institutionelle, die dokumentiert, vertraglich geregelt und
  was weiss ich noch alles werden muss. Ziemlich verstaendlich also,
  dass sich die Bibliotheken, die helfen koennten, vor der offiziellen
  Uebernahme von Verantwortlichkeiten, die dann ja auch wiederum
  dritten gegenueber rechtfertigt werden muessten, scheuen. Eine
  Ausnahme gibt es nur, wenn eine formelle Kooperation bereits
  etabliert ist.

- - Die eigene Datenbank bei einer fremden Institution zu aktualisieren
  ist ein nichttriviales Problem, schliesslich ist der Normalfall,
  dass viele Anstrengungen unternommen werden, schreibende Zugriffe
  von aussen moeglichst fruehzeitig zu unterbinden. Heutzutage ist
  es ja nicht einmal mehr gewaehrleistet, dass eine .zip-Datei in
  einem Mail-Attachment den Empfaenger erreicht!

- - Bibliotheken wollen keinen Avanti-Server, sondern einen OPAC.
  Eine helfende Bibliothek ist dann fast sofort in der Situation,
  nicht nur Avanti aufzusetzen, sondern auch beim Aufsetzen des
  Webservers helfen zu muessen. Und dann stellt sich heraus, dass
  bei der geholfenen Institution Skripte nicht erlaubt sind, oder
  ueberhaupt keine geeignete Web-Praesenz vorhanden ist. Auf die
  helfende Institution kommt dann ein unueberschauberer Mix von
  Internet-Beratung, Hilfe beim Aufsetzen von Webseiten und
  Konfiguration des allegro-OPACs zu.

- - Wenn diese Klippen umschifft sind, stellt sich heraus, dass
  Layout-Anpassungen, Integration in das Lieblings-CMS und
  Praesentation unter geeigneten URLs benoetigt werden, das sind
  eigentlich Aufgaben, die frueher (vor CMS) Webdesigner erledigten,
  und heute typischerweise an spezialisierte Dienstleister vergeben
  werden. Bzw. die spaetestens hier von der helfenden Institution
  verlangen, auch noch allgemeines Webhosting fuer eine zu
  erfindende Subdomain ihres Partner zu uebernehmen, was dann
  wiederum spezifische Kenntnis und Beratung erfordert, denn dazu
  muss ja das DNS [verkuerzt:] beim regulaeren Webhoster ergaenzt
  werden etc. pp.

Fuer mich ist ziemlich klar, dass eine hilfswillige Bibliothek
bei solchen Anforderungen ziemlich schnell die Notbremse ziehen
muss, aber auch bei Ihrer Idee 2 koennte es sein, dass zwischen
dem Angebot eines Hostings und denen, die dies eigentlich nutzen
wollen, eine tiefe Kluft bleibt.

[Es gibt eine 1998 von mir erstellte "Checkliste WWW-Anbindung"
http://www.sub.uni-hamburg.de/informationen/projekte/hans/wwwcheck.htm
Diese Checkliste hat bereits extrem viele Einzelpunkte, und doch
behandelt sie nur den aus heutiger Sicht "trivialen" Fall, dass die
Institution potent genug ist, eigene Server zu betreiben]

Anbieter anderer Bibliothekssysteme und auch zeitweilig die
TU Braunschweig sind einen anderen Weg gegangen, und bieten
kleinen Institutionen auf einem zentral betreuten Server einen
08/15 OPAC an, der vom Layout wenig Modifikationsmoeglichkeiten
bietet (was aber oft fuer die "regulaeren" OPACs der Bibliothekssysteme
genauso gilt). Das ist fuer viele - gerade kleinere - Institutionen
gewiss akzeptabel, zumindest mittelfristig. Clientseitig geloest
werden muss dann nur noch das Problem, die Datenbank bei Bedarf
auf den Server zu uebertragen, was nicht weiter problematisch ist,
weil im Gegensatz zum oben geschilderten Szenario der Server ja
fuer solche Uebertragungen eingerichtet sein sollte (http-Upload
aus dem Browser heraus z.B.).

Ich sehe bei dieser 08/15-Loesung allerdings das Problem, dass
eigentlich jede Bibliothek interessante zusaetzliche Datenfelder
und interessante Spezialindizes hat, die optimal auf die gesammelten
Daten eingestellt sind und bei einer Standard-Praesentation u.U.
nicht mehr nutzbar sind. Allerdings gibt es vermutlich viele
Anwender, die es zwar geschafft haben, einen allegro-OPAC im
Selbst-Hosting ans laufen zu bringen, von der individuellen
Konfiguration von acwww25, populo oder phpac/ruckzuck dann jedoch
lieber Abstand genommen haben :-(

Eigentlich ist es also wirklich so: Die objektive Klippe ist der
Betrieb von avanti, denn das ist fast nirgends erlaubt. Das Anmieten
einer (virtuellen) Maschine, auf der man avanti dann selber installieren
kann, kostet m.W. mindestens EUR 12,- im Monat bei kommerziellen
Providern, die muss dann aber betreut werden, damit sie nicht bei
naechster Gelegenheit zur Viren- und Spamschleuder mutiert. Finanziell
halte ich das auch bei kleineren Institutionen fuer zumutbar, aber dazu
raten  kann man wegen der erhoehten Verantwortung eigentlich nicht.

Uneigentlich benoetigt wird jedoch ein universelles Plugin, das fuer
jedes Web-Layout und jedes CMS der Vergangenheit und Zukunft vorbereitet
ist und - einmal eingestoepselt - OPAC-Funktionalitaet bietet. Und damit
waeren wir schon fast wieder bei Ihrer Idee 1: Das Plugin muss vom Code
und der Funktionalitaet her so trivial sein, dass es jede Web-Agentur
auf jedes Integrationsprodukt einfach anpassen kann, viel komplizierter
als eine flache Tabelle aus "Verfasser, Titel, Jahr, Signatur" duerfte
es also nicht sein. Avanti braucht es fuer so etwas wirklich nicht
mehr, womit also auch dieses Problem geloest ist :-(

Was nun - zwischen "eigentlich" und "uneigentlich" - wirklich
realistisch ist, weiss ich leider nicht. Im Prinzip ist ja u.a. die
Anleitung von Herrn Schoenberger (
http://www.allegro-c.de/doku/avanti/avinstal.php ) unglaublich nah an
der uralten Allegro-Idee, die man heute "empowerment" (der Anwender)
nennen wuerde. Und wenn man erst einmal einen funktionierenden
OPAC auf einer Testmaschine im Intranet hat, dann kann man in
Zusammenarbeit mit Fachabteilungen und ggfls. deren ueblichen
Dienstleistern sukzessive die Einzelkomponenten und ihr Hosting
optimieren, bis dann ein extern recherchierbarer OPAC herauskommt.
Ich hoffe sehr, dass diese Anleitung vielen geholfen hat und helfen
wird, ich fuerchte jedoch, dass diese vielen aber doch nur jene
sind, die sich auch sonst irgendwie durchgewurstelt haetten, weil
das technische Grundverstaendnis fuer Internetanwendungen bereits
genug entwickelt war. Wie gross die Menge der Anwender ist, die sich ein
noch niederschwelligeres Angebot wuenschen, und aus welcher
Dokumentation oder Dienstleistung das bestehen koennte, weiss wohl
niemand. Ich glaube sogar, dass das Artikulieren eines Beduerfnisses
in diesem Bereich (mal abgesehen von der allereinfachsten Aussage
"Wir wollen auch eienen OPAC") bereits mehr technisches
Grundverstaendnis erfordert, als diese Zielgruppe besitzt...


viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwmWkENVh3bB0lwMRAgSMAJ4vR8BLKN7dHzXNOb1UVMxFjFae/gCeLzQY
dioGEEgX458Yk+ElensE+wY=
=mLQL
-----END PGP SIGNATURE-----