Einloggen
[c] [test] [fefe]

/c/ – Pufferüberlauf


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Felix Tue, 17 Nov 2020 11:12:30 GMT Nr. 41428
    Ist ein Feature und kein Bug. Schlaufonkrebs soll ferngehalten werden.
  • [l] Felix Tue, 17 Nov 2020 11:33:02 GMT Nr. 41433
    >>41428
    nun sind Smartphone halt da.
  • [l] Felix Tue, 17 Nov 2020 13:56:27 GMT Nr. 41461
    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.
  • [l] Felix Tue, 17 Nov 2020 16:24:39 GMT Nr. 41514
    >>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.
  • [l] Felix Fri, 04 Dec 2020 16:15:43 GMT Nr. 43061
    >>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:
    /api/boards
    /api/BOARD/?p=PAGE
    /api/BOARD/THREAD

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

  • [l] Zuse ## Admin Sat, 05 Dec 2020 05:14:41 GMT Nr. 43067
    >>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.
  • [l] Felix Wed, 23 Dec 2020 16:28:05 GMT Nr. 44336
    >>43067
    Karl, hast du dich jetzt entschieden in welche Richtung und wie das jetzt weiter gehen sollte?
  • [l] Zuse ## Admin Sun, 27 Dec 2020 12:44:59 GMT Nr. 44507 SÄGE
    >>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.
  • [l] Felix Sun, 27 Dec 2020 23:31:28 GMT Nr. 44542
    >>44507
    und dann Karl? was soll ich mit dem Fork, das bei mir lokal laufen lassen?
  • [l] Felix Tue, 29 Dec 2020 01:07:50 GMT Nr. 44577 SÄGE
    JPG 670×534 119.3k


[Zurück]
[c] [test] [fefe]