[Allegro] ORDA in a99: rückkehr zu ORDA nicht möglich!

[Bernhard Eversberg]

Am 08.12.2011 10:49, schrieb Thomas Berger:
>
>> Aber ok, hier isses:
>>    https://svn.allegro-c.de/svn/download/flex/o-mkview.flx
>
> Haben Sie die Flexe in mehreren Repositories? Irgendwie wirkt
> es beunruhigend, wenn Sie die Adresse angeben (zu muessen glauben).
>
Unfug. Hiermit sollte nur das Heranholen der Datei auf einen
Mausklick reduziert werden, auch für jene, die da nicht ständig
mit dem SVN hantieren.

> Ich sehe das Einchecken in die Quellenverwaltung nicht so sehr
> als x-ten Distributionskanal sondern als Kommunikationsweg:
>... usw. usf.

Ja. Es gibt aber noch andere Kategorien von Nutzern.

Lieber mal was zu den aktuellen Fakten:

Was mal zu sagen ist, das wäre, daß die Umarbeitung der alten,
den 16bittern zugrunde liegenden C-Quellen und deren Harmonisierung
mit den neueren C++-Programmen doch einige Kraft gekostet hat, und
bei solchen Projekten nervt einfach fast alles andere, was dann
nebenbei anfällt, wie z.B. gut(gemeint)e Ratschläge, sorry. Ich
nerve dann mal gerne dagegen an.
Es ist nun aber nicht nur Licht am Ende des Tunnels, es wird bald
die Freigabe geben für die Programme import, index, qrix und
srch, alles 23bit und auf einheitlicher Codebasis mit den
C++-Programmen von a99 und acon. Einheitlich sind dann vor allem
die bisher getrennten C bzw. C++-Quellen der Index-Grundfunktionen,
die sind dann exakt identisch. Wie man sich sowas eigentlich vorstellt,
wie es sich aber auf den verschlungenen Pfaden einer jahrzehntelangen
Entwicklung nicht einfach von selber ergibt. Ach so, und unter Linux
bzw. Solaris kompilierbar werden sie auch sein, die neuen Teile.

Anders als mit dieser Quellcode-Harmonisierung wäre aber OpenSource
kaum akzeptabel gewesen, es bleibt auch so alles schwierig genug. Wir
mußten da also durch und sind es nun. Ufff.
Insbes.  srch  wird dann auch leicht erweiterbar sein, ohne in alle
möglichen Dateien eingreifen zu müssen. Ein kleines Schnittstellen-
Modul enthält Unterprogramme, in die man eigene Manipulationen
an den Datensätzen oder -Feldern einbringen oder sonstwelche
Zusatzaktionen in den Export einbauen kann. Lohnend wird das wohl
nur sein für Fälle mit riesigen Exportvolumina, weil dann srch
viel schneller sein wird als a99 oder acon, bei welchen man ja
mittels FLEX längst sonstwas eigenes einschieben kann. Aber immerhin,
srch32 wird in dieser Hinsicht keine BlackBox, sondern leicht
aufbohrbar.

Mehr in Bälde. Dann wird auch Gelegenheit sein, hoffen wir doch, für
Verbesserungen am Repositorium u. dgl. Und danke im Voraus für den Rat,
sowas doch besser vorher gemacht zu haben.

B.E.