[Allegro] a99: Problem mit mittellangen Zeilen bei get

[Thomas Berger]

Lieber Herr Eversberg,

>> Nun ist es aber so, dass "get" entgegen der Dokumentation nicht
>> immer ganze Zeilen liefert, sondern bei 2048 Bytes abschneidet
>> (das naechste "get" liefert dann die naechste Portion).
>>
> Aha, da hatten wir nicht antizipiert, daß es Fälle mit noch längeren
> "Zeilen" geben mag. Wir könnten das auf 32.000 aufbohren, wäre das denn
> wohl genug?

Mitnichten (das konkrete Repository hatte ich bislang immer nur
mit MODS-Daten getestet, da war alles huebsch eingerueckt. Mit
METS hingegen kommt eine 48 kB lange Zeile, dabei werden nur
laecherliche 10 Datensaetze pro Portion geliefert.

MABXML und MARCXML werden im SRU-Kontext auch gerne mal ganz ohne
Zeilenvorschuebe ausgeliefert, in Code4lib (?) lief dieser
Tage eine Diskussion, wie man MARC in JSON packt, (Loesung z.B.
ein "['" davor und ein "']" dahinter) und wie es wohl aussehen
koennte, wenn mehr als ein Datensatz zu transportieren waere.

Bei in HTML-Seiten etc. direkt in den Quellcode eingebetteten Graphiken
bin ich mir auch nicht sicher, ob dabei nicht extrem lange
Zeilen entstehen koennen.


> Die Funktion könnte am Ende ein NewLine mitliefern, wenn die
> gelesene "Zeile" kürzer war, oder eben nichts, wenn sie länger war.
> Was genau sollte also am besten passieren? Wobei bestehende Anwendungen
> wohl besser nicht durch eine Änderung betroffen werden sollten.

Das "\n" am Zeilenende nicht wegzuoptimieren waere damals wohl
die schlauere Art gewesen, "get" zu implementieren. Dafuer ist
es nun aber zu spaet.

Ginge es nicht, einen Errorcode zu setzen ("truncated")?

Allerdings muss dann auch noch das EOF gesondert bedacht
werden, es kann ja sein, dass am Ende der letzten Zeile
der Zeilenvorschub fehlt, ohne dass die Zeile trunkiert
ist (bzw. sie ist trunkiert in dem Sinne, dass die Anwendung
entscheiden muss, ob ein Zeilenende zu ergaenzen ist,
gleichzeitig liegt aber bereits "EOF" vor...).

Brrr. Zeilenweise und simultan groessenbegrenzt ist nicht
wirklich trivial.

Anderer Ansatz: $@ ist ja system-reserviert. Kann nicht get
die Null oder mehr Zeichen, die tatsaechlich abgeschnitten
wurden, als Seiteneffekt in $@<irgendwas> hinterlegen?

Dann kann man durch Ersatz bisheriger

write newline

durch

var $@<irgendwas>
if not "" write newline

die Situation wirklich sauber hinbekommen, und die Aenderung bringt
auch nur dort ein geaendertes Verhalten, wo vorher Unfug wg. zu langer
Zeilen passierte.

viele Gruesse
Thomas Berger