[Allegro] get I kumuliert

[Thomas Berger]

Lieber Herr Eversberg,

>> ... Es hilft, vor jedem "get I" die iV2 zu leeren:
>>
>> var ""
>> ins $
>> var ...
>> get I
>>
> 
> So ist es, und das hätte zumindest in die Doku  xget.rtf  gehört,
> und wäre es denn jemals aufgefallen, stünde es auch drin.

Das mit der iV2 ist etwas undurchsichtig, als es vor einigen
Wochen um die Fehlerbedingungen von "F<url>" ging, hatten
Sie auch schon etwas dazu gesagt.

>> sowie anschliessend auf den Body der HTTP-Response einschraenken:
>>
>> var (b"^M^J^M^J")
>>
> Ja, der HTTP-Header ist bei acon mit drin, und auch das hätte in der
> Doku zu stehen - oder wir sollten Sorge tragen, ihn programmseitig zu
> entsorgen.

Im Fehlerfall *muss* der Header zugreifbar sein, nur daraus
kann man zweifelsfrei den HTTP-Status ablesen.

Bei mir laeuft einiges ueber einen Squid-Proxy, der liefert evtl.
eine HTML-Seite, wo der Zielserver nur einen HTTP-Statuscode
liefert - das ist aber durchaus korrekt, die meisten HTTP-Errorcodes
erlauben einen Body.


> Damit ergibt sich die Frage: Sollen wir ändern, oder soll's so bleiben
> und nur die Doku ergänzt werden? Die Umgehung des zweifelhalften
> Features ist zwar immerhin leicht, aber unnötige Diskrepanzen zwischen
> .job und .flx sind doch unerfreulich.

Ich weiss nicht genau, woher die Zusatzspeicherung in der iV2
motiviert ist: eigentlich nutzt man sie gerne, um die iV zu
sichern, bevor man etwas schwerwiegendes wie "get I" veranstaltet -
dass das dann so schwerwiegend ist, direkt diese Sicherung mit
zu ueberschreiben, muss deutlicher als bislang in die Doku (die
laesst sich so lesen, als betraefe der iV2-Hinweis eben nicht
"get I", sondern nur "open"..).

Ich koennte auch damit leben, wenn in der iV2 die komplette Response
abgelegt wird und in der iV nur der Body: Eine typische Sequenz
stelle ich mir vor als

var 'http://d-nb.info/gnd/' $gndid '/about/marcxml'
get I
if cancel jump neterror
if not %xmlns="http://www.loc.gov/MARC21/slim"% jump fetcherror

und wenn bis hierhin noch alles o.k. war, dann enthaelt die iV
noch den urspruenglichen Inhalt (und der Anwender wuerde den
mit "ins $" eigentlich selber in die iV2 praktizieren, wenn er
denn moechte).

viele Gruesse
Thomas Berger

N.B.: Die Doku gehoert an dieser Stelle noch aus anderen Gruenden ueberarbeitet:
"Internetdatei" und "dynamische URL, [die '.php' enthaelt]" sind Konzepte, die
es ausserhalb der allegro-Doku nicht bzw. so nicht gibt. Es geht um URIs
als Adressierung von Ressourcen (oder IRIs oder ist das zwischen a99 und
acon ggfls. sogar unterschiedlich, wenn z.B. Umlaute enthalten sind?), und
einige dieser Adressierungsschemata (file:, http:, https:, ftp:) sind
aufloesbar und auf die zugehoerige Resource kann dann zugegriffen werden.
Das Ergebnis dieses Zugriffs ist dann in der iV (etwas umstaendlich
formuliert, aber "Datei" ist dadurch vermieden ...). In http: und https:-
Requests werden auch die im Schema spezifizierten "Query"-Teile der URI
(das hinter "?") unterstuetzt (und "Fragment Identifier" stillschweigend
ignoriert?)