[Allegro] Vb.207 : V28.5 mit acon (Neues Konsolprogramm)

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

| Also gut daß wir drüber geredet haben. War aber nur ne denkbare Idee,
| wirklich machen wollten wir das nicht.
| Jetzt machen wir erst mal nix, sondern warten drauf, daß sich
| die Anwender einigen, wie sie es haben wollen. Ein Entwurf muß her,
| der genau sagt, wie "acon" aufgerufen werden soll. Wobei klar ist
| und nicht diskutabel, daß es DbDir, DbName und Konfig direkt aus
| dem Aufruf entnehmen muß, alles andere aber im FLEX geschehen kann.
| Wenn aber dann, wie SRCH es kann, NUR eine Grunddatei zu verarbeiten
| ist, sollte es ohne Datenbank auskommen. Wie wäre dann die Grunddatei
| anzugeben, im Gegensatz zur Datenbank? Wohl besser nicht, wie bei SRCH,
| schlicht mit -ddateiname.?!

Die Frage also, soll -d Dateien ohne Datenbankkontext bezeichnen
und dmenetsprechend -b mit Angabe einer Datenbank haeufiger erforderlich
sein (bislan unklar/undefiniert, wenn -d schon eine Datenbank *implizierte*)

Wir haben etwas versteckt derzeit noch eine ziemliche Assymetrie,
die viel mit der Implementierung von "srx" zu tun hat:

Es gibt Volltextsuchen, die Datensaetze betrachten, diese mittels
cstring in die iV bringen und dort als String untersuchen. Verarbeitung
des Datensatzes ist dann aber moeglich. (Bsp.: Volltextsuche aus
Ergebnismengen, oder Konstruktionen die alle Satznummern generieren
und daraus Ergebnismengen bilden), Auch: Suchen durch .alg-Dateien?

Und es gibt Volltextsuchen, die eine Datendatei als folge von
Zeilen mit ansonsten binaeren Daten betrachten, die Test-Moeglichkeiten
sind dieselbern, weitere Verarbeitung ausser 1:1-Ausgabe eher
ausgeschlossen. Bsp.: Szenarien zum Umgang mit .ald-Dateien [!]
Theoretisch muesste es zwar moeglich sein, die binaere Satznummer
herauszuoperieren, umzuwandeln und dann diesen Satz aus der Datenbank
zu laden, das scheint aber sehr umstaendlich.

Es sollte erst einmal untersucht werden, inwieweit man Datendateien
als solche (und eben nicht als Zeilen von Binaerdaten) nutzen kann,
ohne dass ein Datenbankkontext dazu geschaffen werden muss. Das
waere ziemlich gut, z.B. im Hinblick auf die Frage/Szenario von Herrn
Eger neulich: Ich koennte dann (also etwa beim durchsuchen von xy_1.ald)
meinen Datenbankkontext zusaetzlich ueber den Schalter -b einrichten
und alle Nachladungen aus der Datenbank zzz asaettigen.

Echtes Hin- und Herschalten zwischen Datenbankkontexten waere dann kein
so wichtiges Desiderat mehr... Im Hinblick darauf sollte aber hier
festgehalten werden, dass analog dem jetzigen -d und -b die Angabe
_einer_ Datenbank in _einem_ Schalter, also als Pfad\Name oder Pfad:Name
~ oder Name at Pfad ...) wichtig ist.



| Die Übergabe des Jobs ist momentan noch nur über Standardeingabe
| möglich, also mit Umlenkung per <jobdatei. Das könnte, gäbe es dafür
| zwingende Gründe, mit etwas Aufwand noch geändert werden. Auch ist es
| möglich, daß Jobdateien ohne die Zeilen mit & und @ auskommen, wenn die
| Datenbank geeignet mitgeteilt wird. Username und Passwort sind beim
| Aufruf als Konsolprogramm entbehrlich! Als Datenbank-Backend für

... wir brauchen aber den Benutzernamen an Datumsstempeln etc.
D.h. entweder mit -O (oh) wie bei update, oder ueber eine Konstruktion
analog _psw.flx (stelle ich mir schwierig vor, weil da interaktive
Elemente drinstecken koennen).

M.E. auch wichtig die Angabe von -a0 (nur lesende Zugriffe)
bzw. != 0 (schreibende Zugriffe): Man sollte es im Hinblick auf
vielerlei Umstaende vermeiden, Dateien zum schreiben zu oeffnen,
wenn man weiss, dass man nicht schreiben will.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSGuNGmITJZieluOzAQKqBAP7Bx4ZeOPkS1ADZUjzNsutrB+yprSMUSrq
VCNjrTQjy2djaJg7UaP3VidLDlvD8areun6qlpT8KRrIx2HpBmBKxDIgyJeWfgc9
/7I070b8cdyIOBWxL5HPzCri+0/h3FjKW88dxjN+1BNGwuHbNZQ2eptZBgUqAbtW
1EUMgTAPog4=
=HuIy
-----END PGP SIGNATURE-----