[Allegro] Desiderate zu persistenten Variablen

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

die Diskussion um die Rohdaten der ISBN International Agency, die
die die Sprachprefixe und die Struktur der Bloecke innerhalb der
Sprachprefixe enthalten und damit die korrekte Strichsetzung in ISBNs
ermoeglichen, hat mich einmal wieder dazu gebracht, ueber die
"externe" Datenhaltung in Indizes nachzudenken, also etwa ueber das,
was die "persistenten Variablen" &xy leisten.

Solche Daten als Binaerindizes auszuliefern, halte ich fuer keine
gute Idee, bei ca. 20 freien Buchstaben sind Namenskonflikte eigentlich
sofort faellig, ausserdem (wir hatten neulich ja Sprach- und Laender-
codes sowie die fuer die RDA-Katalogisierung faelligen Picklists)
kommt man recht schnell zu einer gewissen Anzahl.

Insofern denke ich eher in die Richtung, ein (etwa tabellarisches)
"Dataset" mittels eines "Namespace"-Praefix in *den* Index fuer die
persistenten Variablen einzusortieren.

Variablennamen wie

&name:space#elementx

oder sogar

&http://example.org/path/to/resource#elementx

scheinen kein Problem darzustellen, d.h. man kann einerseits URIs
entsprechend den Traditionen im Semantic Web und andererseits
Praefixe wie in der MARC-Katalogisierung zur Kennzeichnung des
Datasets verwenden, wobei "#" dann ein geeigneter Delimiter zwischen
Praefix und "eigentlichem" Namen ist.

Das ist soweit prima: Man koennte also sofort eine Verabredung treffen
und dokumentieren, dass "geteilte" Nutzung des oder eines Index
mit Persistenten Variablen mittels Namespaces und "#" als Delimiter
erfolgen soll.

 % --

Will man das allerdings "managen", so wird u.a. eine Funktion benoetigt,
die (etwa vor dem erneuten Laden) alle Eintraege fuer ein gegebenes
Praefix loescht. Dafuer haben die persistenten Variablen keine
Funktion, mit einiger Muehe kann man es allerdings in der Flex-
Sprache programmieren, naemlich mittels qrix den entspechenden
Registerbereich laden und dann die entprechenden Loesch-Setzungen
formulieren. Soweit auch gut.

Allerdings: mittels "set &xn" koennte ein Benutzer /den/ Persistenz-
Speicher weg vom Default ~z: bewegt haben. Dann muesste man wissen,
wohin, damit das qrix-Kommando entsprechend formuliert werden kann.
Derzeit fehlt ein cstring-Kuerzel, ueber das man die aktuelle
Setzung von "set &..." auslesen kann.

 % --

Eine Variante waere (um /den/ Speicher fuer persistente Variablen
nicht vollzumuellen), stets einen festen alternativen Index zu
nehmen. Hier gibt es ein Problem analog des vorigen: Ich will dann
natuerlich die /aktuelle/ Setzung von "set &" auslesen, damit ich
sie nach den Operationen wieder restituieren kann.

 % --

Und es gibt ein weiteres Problem: existiert der ueber "set &"
eingestellte Index nicht, wird er nicht erzeugt, sondern
Zuweisungen an die persistenten Variablen landen in anderen
Indizes (ixadd desgleichen). Die Dokumentation schreibt, man solle
einfach Kopien von cat.azx so verteilen, wie man lustig ist,
allerdings duerfte cat.azx als Ort "des" persistenten Speichers
ja ueber kurz ueber lang Inhalte haben und ist dann als Kopiervorlagen
fuer einen leeren Index nicht mehr wirklich gut geeignet.

Ich denke, job (acon) und flex (a99) sollten in die Lage versetzt
werden, auf die Existenz spezifischer Indizes zu testen (ist die
Dateisystem-Operation "fsize" auch bei access=0 erlaubt?) sowie
"leere" Indexdateien bzw. -register zu erzeugen (nicht unbedingt
ganz implizit bei ins &... bzw. ixadd, aber ueber ein zu
implementierendes ixcreate oder so, mindestens Schreibzugriff
vorausgesetzt, evtl. auch ein fuer den "Datenbankadministrator"
reserviertes Access-Level: Nur beim ORGansisieren von Hilfstabellen
entsteht ja die Notwendigkeit, vor dem erstmaligen Laden einer
"externen" Datensammlung evtl. eine noch nicht vorhandene Indexdatei
anlegen zu muessen).

viele Gruesse
Thomas Berger