>>43512
Unwahrscheinlich, außer es will jemand anderes daran basteln. Zumindest wäre es jetzt leichter, da der neue BBCode-Parser eine Schnittstelle besitzt, mit der man die Ausgabe in einen String umleiten (oder direkt als JSON enkodiert ausgeben) könnte. Es wäre auf jeden Fall ein guter Einstieg, um sich mit dem Quellkot von Dietchan vertraut zu machen.

Ansonsten gilt: Wer eine Äpp programmieren will, muss das HTML parsen. So ein Fach ist das.

Ist schon geil. ja. Wird es eine API für JSON geben? Dann wäre auch eine Händy Äpp denkbar

Der BBCode-Parser wurde neu geschrieben und lässt sich nun leichter erweitern. Als direkte Konsequenz daraus wird nun auch
<Orangetext
unterstützt.

Passend zum Bretttitel unterstützt der [code]-Tag nun Syntaxhervorhebung für C. Benutzt werden kann diese per [code=c]:

>>43344
https://kohlchan.net/addon.js/hashcash/?action=get

>>43343
Hä, kannst du link schicken?

>>43341
Bitte schön

>>43315
Hab leider kein Krypto. War nur eine Überlegung für Weihnachten. Weißt du vielleicht ob man kohlchan Bargeld spenden kann?


PS:Wo ich grad mit einem Admin schreibe :Was ist eine Säge?

Danke für das Angebot. Bargeld ist schwierig, Krypto würde aber gehen.

>>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.

>>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):

Ist Kot eigentlich schwerer zu teleportieren?
Die Entropie ist ja gestiegen durch die Verdauung.

Unfassbar welche Menge Kot gerade wieder aus meinem Dickdarm kam!

>>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.

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.

>>41428
nun sind Smartphone halt da.

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