[Allegro] Was bringt V25.4.1 ?
B.Eversberg
ev at biblio.tu-bs.de
Fr Apr 1 09:06:36 CEST 2005
Eine kurze Geschichte von langen Dateinamen
-------------------------------------------
Vor einigen Tagen hat sich T. Berger wieder einmal mokiert ueber
unsere für ihn "unglaublichen Bemühungen", mit Dateinamen des Typs 8+3
auszukommen. Er konnte nicht ahnen, daß wir unmittelbar vor
dem Durchbruch standen, Dateinamen beliebiger Länge in ganz neuer
Weise zu nutzen. Notwendig war dazu eine neue Windows-Version, die
unter dem Codenamen "Rattlesnake" in Onkel Bill's hektischen
Hinterzimmern vorbereitet wird. Über Beziehungen konnten wir eine
schon recht stabile pre-Beta-Version ergattern. Der Handelsname
wird wahrscheinlich Windows XXXL sein. Zu den für uns
interessanten Features gehört die echt unbegrenzte Namenslänge, gepaart
mit der Erlaubnis, in einem Dateinamen nun wirklich endlich auch
jedes Sonderzeichen benutzen zu können. Obendrein wird die Anzahl
der Dateien in einem Ordner nach oben unbegrenzt sein, und zwar ohne
Performanceprobleme.
WIE wir das alles aber ausnutzen, darüber wird selbst der gute Bill
noch staunen. Hier und heute enthüllen wir es:
Das Naheliegende ist ja, daß man z.B. Parameterdateien wird machen
wollen mit Namen wie
"Exportparameter zur Sortiervorbereitung mit Ordnung nach Verfasser und
Erscheinungsjahr.A-Schema-allegro Export-Parameter"
Bislang bekam so eine Datei einen spröden Namen wie S-VERFJ.APR !
Oder ein FLEX-Name könnte so lauten:
"FLEX-Datei zum Berechnen des Osterdatums zwischen 1700 und 2199 nach
dem Gauss-Algorithmus.FLEX"
und dazu mußte man bisher barsch GAUSS.FLX sagen.
Wie gesagt, das sind die NAHEliegenden Dinge. Darauf würde jeder kommen,
noch ganz ohne Querdenkerei. Darin liegt noch keine Innovation.
Der Zugewinn an Transparenz ist nicht zu verachten, sicher, aber man
kann weiter gehen, sehr viel weiter. Die Länge dieser Beispiele liegt
noch deutlich unter 256. Diese Zahl war uns dennoch immer willkürlich
vorgekommen, weshalb wir noch gezaudert hatten, uns drauf einzulassen.
Warum gerade an dieser Stelle stehenbleiben, das ist doch alte
8-bit-Technologie!
Und richtig: auch Bill, der alte Visionär, hatte das so gesehen.
Windows-XXXL wird die Grenze sprengen: Dateinamen gänzlich beliebiger
Länge werden möglich.
Naja, 64bit wäre die Grenze, das heißt aber 2 hoch 64, und das ist
eine Dateinamenslänge, mit der wir hemmungsfrei durchatmen können, würde
doch der längstmögliche Name quer durchs gesamte Universum reichen.
Es wird, das legen wir hiermit offen, eine Version V25.4.1
geben, und die bricht entschlossen die Brücken hinter sich ab.
Dies sind die überraschendsten Fakten:
1. Die TBL-Datei fällt weg, denn sie wird überflüssig
2. Die ALD-Dateien fallen ebenfalls weg - eben deshalb braucht man
keine TBL mehr!
Aber wo bleiben die Daten? Genau das ist die Innovation. Wenn der
Dateiname beliebig lang sein kann, dann ist z.B. dies ein
möglicher Dateiname:
cat_12345-#00 896970--#20 Shakespeares Sonette in deutscher Übersetzung
: Stephan George und Paul Celan--#30asl--#30leng--#31pShakespeare,
William--#31uLyrik--#40 Lengeler, Rainer--#74 Opladen--#76 1989--#85
Vorträge. Rheinisch Westfälische Akademie der Wissenschaften
Geisteswissenschaften ; G 297--#87 3-531-07297-8--#90 2678-9716
Sie erkennen es: da haben wir den Dateinamen einfach aus dem kompletten
Inhalt eines Datensatzes gebildet. Der Witz: Die Datei, die so heißt,
die ist leer - sie braucht keinen Inhalt, der steckt ja bereits
komplett in ihrem Namen. 12345 ist die interne Nummer, die bei jedem
Indexeintrag dabei ist und mit der man den Satz bisher nur über die
TBL fand. Jetzt findet man den Satz ohne diese Krücke, weil sein
Dateiname mit der Nummer beginnt.
"Haltstopp!" werden jetzt manche sofort rufen, "warum dann nicht gleich
XML an dieser Stelle, statt der kryptischen Kategorienümmerchen?"
Weil XML, und dabei bleibt's, im Innern einer Datenbank nichts
zu suchen hat, basta! Das wäre bestenfalls Stoff für einen Aprilscherz.
Jeder einzelne Datensatz wird also eine Datei sein, eine Datei mit einem
schön langen Namen und ohne Inhalt. Das hat zur Folge: Kein Speicherbedarf
mehr für die Daten! Wenn man auf dem Datenverzeichnis den Befehl "dir"
gibt, bekommt man keine dürre Liste mehr von wenigsagenden Dateinamen,
sondern gleich den ungeschmälerten Inhalt der Datenbank. Beim Zugriff
auf einen Datensatz braucht keine Datei mehr geöffnet zu werden, das
spart kostbare Millisekunden, es braucht nur intern ein dir-Befehl
gegeben zu werden, z.B.
dir cat_12345-*
und das Ergebnis ist schon der Datensatz. Ein simpler FLEX, und was
schnelleres gibts ja nicht, macht dann aus dem Dateinamen die interne
Form des Datensatzes.
Der dir-Befehl kennt ja die Linkstrunkierung, ergo kann man auch sagen:
dir *#00 896970*
um denselben Satz zu bekommen, oder
dir *Sonette*
um alle Sätze zu erhalten, in denen "Sonette" irgendwo steht. M.a.W.,
auch die Volltextsuche wird einer simplen Systemfunktion überlassen.
Aber noch mehr:
Das Speichern eines Satzes vereinfacht sich extrem: seine Datei wird
schlicht umbenannt. Weil sie ihre Nummer behält, bleibt der Zugriff
davon unberührt.
"Aber", hören wir schon die nächste Frage voraus, "wie soll denn
die Vergabe der internen Nummern gehen, wenn die TBL wegfällt?"
Dazu gibts einen Satz mit der Nummer 0, der bisher nicht sein
konnte. Und dieser enthält immer die zuletzt vergebene Nummer.
Genauer gesagt, dieser Satz ist eine Datei mit dem Namen
"cat_0-nummer" und enthält - gar nichts. Diese Datei wird
umbenannt in "cat_0-nummer+1", um die nächste Nummer zu vergeben,
das ist alles! Eine Umbenennung kann nicht gleichzeitig von zwei
Plätzen aus geschehen, das System sorgt also zwanglos selber für
die Vermeidung von doppelten Nummern.
Das neue Konzept ist deshalb auf der Systemseite robust und kompakt,
spart aber mit einem Schlag die ganze komplexe Datensatzverwaltung
ein, die wir bisher hatten. Die irritierenden, betulichen Leerschlüssel
im Reg. 1 werden obsolet, was nochmals Platz spart.
Der Index und die STL/RES bleiben unberührt! Die Umstellung wird also
nur die ALD-Dateien betreffen und kann praktisch in fliegendem
Wechsel geschehen. Keine Parameterdatei ist zu ändern.
Das Ganze steht im Einklang mit unserer Entwicklungsphilosophie, die
da lautet: "Wo es nicht notwendig ist, ein Programm zu schreiben, da
ist es notwendig, KEIN Programm zu schreiben." Das gilt auch und gerade
für Unterprogramme, von denen jetzt so einige entfallen.
Der tiefsinnige Satz stammt von Montesquieu (das war der mit der
Gewaltenteilung und den "Persischen Briefen"), nur daß es bei ihm um
Gesetze ging statt um Programme.
Die längerjährigen Anwender werden jetzt einwerfen: Moment mal,
ihr habt vor ein paar Jahren versprochen, eine Version zu liefern,
mit der man die riesigen Platten besser füllen kann! Damit seid ihr
noch immer nicht übergekommen, aber jetzt auf einmal dieses: Dateien,
die GAR keinen Platz mehr brauchen, wie reimt sich DAS denn zusammen?
Nun, das ganze Umfeld hat sich ja gewandelt. Was jetzt ansteht, ist
die Integration von Multimedia-Dateien. Die kommen ganz neu hinzu
und BRAUCHEN Platz ohne Ende - voilà, wir machen ihn frei. Das ist
unsere zweite Innovation: Zu jedem Buch kann man eine Video-Datei
speichern, in der eine angenehme junge Dame (oder ein distinguierter
Herr, wenn es Literatur gewisser Kategorien ist) das Buch vorzeigt,
dann aufblättert und Seite fuer Seite zeigt und wahlweise vorliest.
Das Filmen der Bücher mit einem normalen, hochauflösenden digitalen
CamCorder geht schneller als das Seite-fuer-Seite Scannen.
Der Nutzer kann ja an jeder Stelle stoppen und die Seite dann lesen
oder lesen lassen, bzw. Schnellleser können natürlich auf
Schnelldurchlauf schalten.
Dies geht über die Pläne von Google entscheidend hinaus und
sichert unsere Führungsposition im Konzert der
Informationsbereitsteller im Netz.
Allerdings werden nun diejenigen Anwender auf den Plan treten, die
aus weltanschaulichen Gründen mit Videos nichts zu tun haben wollen
oder bei denen die Sache keinen Sinn macht. Deren leere Platten
werden nun noch leerer und kommen dann wegen der Unwucht bedenklich
ins Schlingern. Da müssen wir einen Ausgleich bieten. Angedacht wird
eine Ausweitung der Indexiertechnik. Linkstrunkierung und Phrasen-
indexierung hatten wir ja schon, beides bringt schon was, aber leider
nicht genug, denn die Indexdatei kann ja nur bis 2 GB groß werden, und
daran wird auch XXXL nichts ändern können. Man wird wohl die alte Idee
der Einrichtung zusätzlicher Indexdateien nochmal ventilieren müssen.
Könnte man, sagen wir, 256 Indexdateien anlegen, würden damit bis zu
512 GB vom Leerlauf verschont. Und wenn man's recht bedenkt: warum
an dieser Stelle stehenbleiben?
Wann V25.4.1 freigegeben wird? Sobald Onkel Bill ausliefert, vorher
kann ja keiner was anfangen damit!
P.S.
"Es klapperten die Klapperschlangen
bis ihre Klappern schlapper klangen."
Was natürlich nichts über lange Dateinamen oder neue Windows-Versionen
im allgemeinen aussagt...
Mehr Informationen über die Mailingliste Allegro