[Allegro] Ist der Ruf von allegro "antiquiert"? Pamphlet Numero ZWEI

[Anando Eger]

Lieber Herr Berger,

> inst-all etwa als Demo- und Bastelsystem
> 
> inst-kern als Kernsystem, das von einem noch zu erstellenden,
> freien, modularisierten *Bibliothekssystem* "OpenAllegro"
> und weiteren zu nutzen waere. Hierzu gehoeren m.E. hauptsaechlich
> gewisse Konventionen (der Variablenbenennung, und welche
> "Schichten" von Hilfeseiten "Interfaces" zueinander haben sollten,
> und vielleicht ganz wenige Aenderungen an allegro (fehlende
> Includedateien kein "fatal" error mehr). Dazu allerdings ein
> "Konfigurator" (habe schon viele "Konfiguratoren" fuer allegro
> geschrieben, XML-basiert fuer HANS, alcarta-basiert [!] fuer
> allegro-NRW, mit Perl fuer Capriccio, Webbasiert auch einmal
> als Demo, aber leider nie einen mit zufriedenstellendem GUI...)

spinnen wir den Faden doch mal weiter: 
- das Kernsystem erhält einen Mechanismus, mit dessen Hilfe 
  man standardisiert Konfigurationsdaten verwalten kann
  (eine Art allegro-Registry? eine Systemdatenbank?)
- ein Konfigurations-GUI kann Bestandteil eines Grundpaketes
  sein; damit hat der Paketanbieter alle Möglichkeiten in der
  Hand
- es gibt einen standardisierten Eintrittspunkt für die 
  Paketinstallation
- ein "nacktes" Kernsystem fragt dann den Installateur etwa: 
  "Bitte wählen Sie ein Grundpaket aus"

O.k., vieleicht nennen wir das Paket, an dem verteilt entwickelt 
werden soll,  "OpenSchema". ("Allegro" ist ja schon besetzt)
Was müßte vereinbart sein?
(so, wie es mir einfällt)

- Ablageorte für paketspezifische Parameter, Flexe und Hilfe-
  seiten: Momentan käme wohl nur ein DB-Verzeichnis in Frage;
  Was, wenn ein Paket mit mehreren DB's umgehen kann?

- Umfang der vom Kernsystem bereitgestellten Funktionen
  (elementare, konfigurationsunabhängige Flex-Dateien und
  Parameter)

innerhalb des Paketes:

- das Kategorieschama (natürlich ;-)

- Verwendung der Register und symb. Registernamen

- Namenskonventionen für Variablen - nannten Sie schon
  (schön wäre es, wenn die $-Variablen 
  im Flex die gleichen Operationen wie die #u-Kategorien
  erlauben würden - dann wäre es einfach)

- Namenskonventionen für die Flexdateinamen

- Struktur der Quellen, die der Konfigurator verarbeiten 
  kann

- die Funktionalität des Konfigurators selbst
  (Wenn der in Flex geschrieben würde, brauchte man kein
  externes Programm)

- einheitliche Konventionen bei der Gestaltung der Nutzer-
  oberfläche; gefördert z.B. durch Nutzung einer paketeigenen
  allgemeinen Funktionsbibliothek
  Es wäre soooo schön, wenn Unterprogramme in Flex
  * schachtelbar wären (wo ist hier eigentlich das 
   Problem? Ein (Script-)Programmstack müßte doch realisierbar sein)
    
  * lokale Variablen hätten
  
- ein Mechanismus für das Zusammenspiel der (Teil-)Hilfen
  der Paketkomponenten