/meta/ – Diskussionen über Dietchan

Ist ein Feature und kein Bug. Schlaufonkrebs soll ferngehalten werden.

>>41428
nun sind Smartphone halt da.

Das größere Problem ist, dass die Software ausschließlich HTML ausgibt und derzeit keine Anwendungsschnittstelle für die programmatische Abfrage bereithält. Das widerspräche der Anforderung "Web 1.0".
Als bloatfreie Alternative zu JSON (an sich gar nicht so sehr Krebs, mit Ausnahme z. B. der zu kodierenden Zeichen in Strings) könnte ich mir z. B. eine Abfrage von Threads und Posts im Bencode-Format (benötigt lediglich ein Längen-Präfix für Strings) oder, soweit das Datenbankformat stabilisiert ist, sogar als flache Textdatei mit ASCII Record Separator und Unit Separator als Trennzeichen vorstellen.

>>41461
Es ist schon etwas Kot zum Erzeugen und Parsen von JSON im Repository vorhanden (für eine andere Funktion), also wenn dann würde es wahrscheinlich auf JSON hinauslaufen. Aber wie schon gesagt, es widerspricht "Web 1.0". Wer unbedingt eine Äpp will, muss halt das HTML parsen.

>>41514
Für einen eventuellen Fork habe ich mich trotzdem mal damit beschäftigt. Leider ist der gesamte Templating-Code auf direkte Ausgabe ausgelegt, sodass manche Dinge neu geschrieben statt aus export.c übernommen werden müssten – zum Beispiel, wenn man aus Kompatibilität mit der 4chan-API den BBCode aus der Datenbank erst zu HTML parsen und dann für JSON-Ausgabe kodieren möchte. Dietchan besitzt mit seiner Context-Struktur eine I/O-Abstraktion ähnlich BIOs in OpenSSL, die leider an einen Socket und die I/O-Batch-API in libowfat gebunden ist. So kann man auch nicht Code in der Art wiederverwenden, dass die Ausgabe statt als HTTP lediglich im Speicher abgelegt wird (vgl. std::stringstream in C++), was ohnehin weder elegant noch im Sinne des Erfinders wäre.
Weiterhin wären mögliche API-Endpunkte analog zu anderen Bilderbrettern ziemlich begrenzt, zumindest was die Erwartung üblicher Imageboard-Clienten angeht:

Diese hätten keine Entsprechung im HTML-Frontend (wenngleich ein minimalistischer Katalog wie auf Futaba schon toll wäre):

>>43061
Der Aufwand, in bbcode.c eine optionale Ausgabe in einen String (oder gar irgendwas Stream-ähnliches) zu ermöglichen, würde sich wohl in Grenzen halten. Allerdings war eine Refaktorisierung des BBCode-Parsers schon länger angedacht, um ihn leichter erweiterbar zu machen. Momentan ist die Diff-Hervorhebung nämlich nur in einem getrennten Branch notdürftig drangefrickelt. Es wäre schön, wenn es da eine sauberere Schnittstelle gäbe, sodass man auch etwa Syntaxhervorhebungen für andere Sprachen nachrüsten könnte, oder sogar ganz neue BBCode-Tags oder Markdown, falls jemand das will. Wobei ich betonen möchte, dass das alles nicht standardmäßig integriert sein sollte. Es sollten nur die Schnittstellen vorhanden sein, sodass man einbauen kann, wenn man möchte. Der Kot soll dadurch nicht komplexer werden. Vielleicht ist es mal an der Zeit, das umzusetzen.

>>43067
Karl, hast du dich jetzt entschieden in welche Richtung und wie das jetzt weiter gehen sollte?

>>44336
Wer ist Karl? Und was meinst du mit weitergehen? Die Refaktorisierung wurde durchgeführt. Aber ich habe kein Interesse, eine JSON-Api zu programmieren. Jemand anderes kann das aber gerne machen in seinem Fork.

>>44507
und dann Karl? was soll ich mit dem Fork, das bei mir lokal laufen lassen?

>>44542
Ja.