Problem:
- der komplett control-flow ist eigenartig.
- fileupload_page.tpl ist der Endpoint, und löst "fileupload" events aus, die in den Subsystemen verarbeitet werden.
- object_event_handler_fileupload macht dann event_run "TYPE_fileupload", aber dafür gibt es keine Handler. Es gibt aber img_event_handler_fileupload, der je nach Reihenfolge vor oder nach object_event_handler_fileupload aufgerufen wird.
- cht attachment upload ist zweistufig (erst PUT / fileupload, dann via /cht/upload in den Chat verschoben. Da gibt es eine Race-Condition und eventuell auch Diskrepanzen zwischen den Autorisierungsmodellen. Außerdem fällt das unnötig auf die Nase, wenn /upload/ je voll ist.
- fileupload_handler, der ultimative Verschieber der Datei, ruft exit() auf - was etwas unerwartet ist.

Ziel:
- fileupload_page einziger Einstiegspunkt (wie gehabt), hat aber zentralere Rolle.
- die Events liefern [string $prefix, callable $cb, array $methods=["PUT"]] zurück.
- fileupload_page ruft den richtigen Handler auf. Der prüft Rechte und verschiebt.
- offene frage: wer liest php://input?
- einstufiger cht-attachment-prozess: Upload erzeugt gleich neue msg_id.

Offene Fragen:
- Routen-Matching: Exakte Präfixe, Regex-Templates oder Pfadsegmente?
- Was passiert bei überlappenden Präfixen? (throw "coders are stupid").
- Callback-Signatur: Welche Parameter bekommt der Callback? Mindestens $path, $filename, Eingabe-Stream/Temp-Datei; optional $args.
- Rückgabeformat: HTTP-Statuscode + Message + optional JSON mit bbcode, url, filename. JS-Seite muss erweitert werden, um JSON auszuwerten.
- Chat-Attachments und msg_id: Chat-Dateien werden aktuell als <msg_id>-<filename> gespeichert, die msg_id entsteht aber erst beim Einfügen in cht_log. Mögliche Lösungen:
- (A) Beim Upload eine leere cht_log-Zeile anlegen, msg_id für Dateinamen verwenden, später bei Nachrichten-Submit die Zeile aktualisieren. Nachteil: leere/Datei-only-Nachrichten, unsicheres UX. Schlecht.
- (B) Staging-Tabelle für Uploads: Datei bekommt temporären Schlüssel, wird beim Submit der Nachricht zugeordnet. Mehr Komplexität, aber sauberere Daten.
- (C) Chat-spezifisches Präfix mit verändertem Dateinamen-Schema, das ohne msg_id auskommt. Erfordert Anpassung in cht_format_query/cht_get_stored_files.
- (D) cht_upload daran knüpfen, dass ein Text zum Mitschicken da ist.
- Rückwärtskompatibilität: Bestehende URLs (/upload/…, /object_attach/…, /img_attach/…) müssen weiterhin funktionieren, oder alle Widgets/Templates/JS-Dateien müssen angepasst werden.
- PUT vs. POST: Aktuell nur PUT über fileupload_page.tpl. Soll der neue Mechanismus auch andere Methoden erlauben, oder bleibt es bei PUT? Warum _hatten_ wir überhaupt PUT genommen? Das ist zwar korrekt, aber für mich untypisch. Ingos Idee?
- com-attachments. seit ewig offene Frage: Attachments zu Kommentaren leichter machen?