AW: [Allegro] Ist der Ruf von allegro "antiquiert"? Pamphlet NumeroZWEI - vollst. Version

[Andreas Wolf]

Hallo,

Und öhhhhhhhhhhhhhhhhhh..................

Was soll das ? Ich betreue derzeit ungefähr etwa 100 Bibliotheken, und nicht
eine einzige ist mit einer der anderen vergleichbar. Alle wollen was anderes
und alle bekommen genau das was sie wollen.

Sprich: ich habe schon immer alle verfügbaren Konfigurationen (a.cfg,
Neutral usw.) ignoriert, mir für jede einzelne Bibliothek genau die
Konfiguration gebastelt, die gewünscht wird und dann modular (!) mir die
Bestandteile(sprich Umsetzungen der Wünsche der Bibliotheken)
zusammengesetzt.

Ich und meine von mir supporteten Bibliotheken brauchen keine
Standardisierung, NEIN (!), ich lehne jede Art der Standardisierung für
Bibliotheken im WB-Bereich kategorisch ab (für ÖBs ist das natürlich
anders).

Und ich erstelle für meine Bibliotheken immer jeweils eine Möglichkeit des
Updates, durchaus auch teils im vorgeschlagenen Verfahren. Aber die
Installation und jedes Update sieht immer anders aus. Ich und meine
Bibliotheken brauchen keine allgemeinen Installationsroutinen aus der
Entwicklerwerkstatt.

Ich brauche die Flexibilität. Und die fehlt v.a. bei der Oberfläche (ich
weiß, ich wiederhole mich).

Ich lebe und allegro lebt durch den Individualismus. Mitunter anstrengend,
zeitraubend, es lohnt sich aber, in jeder Hinsicht. Der Kunde ist König. Ich
wiederhole es gerne.

Grüsse

Andreas Wolf



-----Ursprüngliche Nachricht-----
Von: allegro-bounces at biblio.tu-bs.de
[mailto:allegro-bounces at biblio.tu-bs.de] Im Auftrag von Anando Eger
Gesendet: Freitag, 15. Juni 2007 17:50
An: Allegro-C Diskussionsliste
Betreff: Re: [Allegro] Ist der Ruf von allegro "antiquiert"? Pamphlet
NumeroZWEI - vollst. Version


bin auf Strg-Enter gekommen - hier die vollst. Version:
(ich h... diese Taste ...)

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, Hilfedateien)

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

- eine (Teilpaket-)Installationsschnittstelle

- ein Updateverfahren, auch Web-basiert, auch für
  Teilpakete

So, das soll vorerst genügen, ich muß weg ...

Viele Grüße
Anando Eger

----------------------------------------------------------------------------
-
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Gustav-Voigt-Str. 24
01156 Dresden
Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
----------------------------------------------------------------------------
-



_______________________________________________
Allegro mailing list
Allegro at biblio.tu-bs.de
http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro