Zeile in Textdatei löschen - aber wie

[Tom]

Hello Dennis,

eine Bitte zu Anfang: Leerzeilen kosten nur ca. zwei Bytes im Archiv. Also sei bitte nicht so sparsam mit der Absatzbildung. man kann dann ein Posting viel leichter lesen, wenn zwichen Frage und Antwort immer eine Leerzeile und zwischen den einzelnen Pärchen immer zwei (oder mehr) Leerzeilen stehen.

Also die URLs werden in der Haupt Datei gespeichert. Würdest du dem User die Möglichkeit geben, ein Bild upzuloaden? Oder soll er nur einen Link zu einem Bild angeben können? Oder soll er gar kein Bild angeben können?

Das ist schon Philosophie. Sicher gibt es mehrere Lösungswege. Alle sind diskussionswürdig. Was aber auf keinen Fall, in die Datei gehört, ist das Bild selbst, denn ein Browser fordert ja jedes Bild über eine URi mit einem eigenen Request an. Es wäre doch dumm, wenn für ein Bild von 100kByte eine Stream-Datei von 50MByte geöffnet werden müsste. Außerdem hatten wir ja 2MByte für die Datei als "Archivschwelle" festgelegt.

... und 100 Bytes Verwaltungsinformatiion und vielleicht im Mittel 200 Bytes Stellungnahme des Guestbook-Admins --> 1.400 Bytes pro Beitrag ergeben --> 336kBytes im Jahr! Es würde also vollkommen reichen, jeweils den 13. Monat ins Archiv zu verfrachten.
Mit anderen Worten: Pro Jahr eine Datei im Archiv.

Pro Jahr eine Datei im Archiv, die jeden Monat um einen Monat wächst.

Die Archivierungs-Push-Funktion sollte unabhängig von der Save-Funktion sein, also entschichtet.
Mit entschichtet meinst du, dass sie nicht serealize() gespeichert werden soll, sondern als sinnvoller Text, eventuell als .html-Datei?

Nein, ich meine, dass das Ereignis, das das abtrennen von einem Monat von der aktuellen Datei auslöst nichts damit zu tun hat, wann und ob eine neue Archivdatei angelegt wird oder siee reorganisiert werden muss oder der Monat nur eingepflegt wird. Die Applikation (Funktionensatz) in der Mitte ist da also die Schnittstelle oder besser Verbindungsstelle.

Da hätte ich dann nochmal eine Frage; Was hälst du für besser?
Siehe oben. Wenn du sie EVA-Regel einhältst (auch wenn die aus dem Museum stammt), kann dir eigentlich nicht viel Böses widerfahren Und dann ist das auch schon mal einen "SelfHTML Creativ" wert.
Was ist denn die EVA-Regel? Hab ich noch nie von gehört.

Asbach HTML gibts nur, wenn einem so was Gutes widerfährt...
Eingabe - Verarbeitung - Ausgabe
Gute alte Batchprogrammierung, die für Dialogprogramm auf PCs lange Zeit nicht mehr eingehalten wurde. Es ist auf einer geschlossenen Maschine auch nicht notwendig. Da kann man on the fly reagieren, also auf jede Taste...

Beim Schreiben müsste man erst count($riesengroßes_Superarray) machen, und dann die nächsthöhere ID nehmen und den Eintrag erzeugen. Dann schließlich ist Gästebuch schreiben.
Ich würde da einen Schritt weitergehen und einen Meta-Record vorschalten über die Datei. Da steht dann auch die letzte vergebene ID drin. So wäre es leicht möglich, Sätze zu löschen, ohne mit der ID durcheinander zu kommen.
Das habe ich jetzt wieder nicht so ganz verstanden, da mit Meta-Record kein Begriff ist. Werden denn gelöschte IDs erneut vergeben? Es wäre vielleicht besser "nein", da man sonst die die Ausgabe nicht so leicht nach Eintragszeitpunkt ordnen kann.

Meta-Daten sind "Daten über Daten", also keine eigentlichen Nutzdaten, sondern eine Bewertung der Darstellung. Die Satznummer gehört ja auch nicht nicht zu den Nutzdaten, denn sie hat überhaupt keinen Nutzen für das Objekt selbst. Sie hat erst Nutzen für den Verwalter der Objekte. Und da hast Du es richtig verstanden, dass man eine einmal vergebene ID kein zweites Mal vergeben sollte, jedenfalls nicht innerhalb einer angemessenen Sperrzeit.

Liebe Grüße aus http://www.braunschweig.de

Tom