hotti: Zeigt her Eure Formulare

Beitrag lesen

hi,

Nein, du wählst einen spezialisierten Ansatz, der nicht verträglich mit bestehenden Konzepten und Denkweisen ist. Es muss ensteht für den Entwickler ein echter Mehraufwand, aber ohne dabei einen qualitativen Mehrwert zu Leisten.

Nicht verträglich betrifft nur den Transport. Die Datenstrukturen bleiben dieselben, egal ob mein Serializer EAV.js oder JSON zum Einsatz kommt. D.h., der Transport-Layer ist austauschbar.

Und ich erzeuge auch nur Sequenzen, jedoch nicht mit textlichen Mitteln strukturiert, sondern auf Byte-Ebene

Das ist eine weitere Spezialisierung, die du vornimmst und die hier keinen effektiven Mehrwert erzeugt. Mit dem Ansatz, den ich hier bewerbe, kannst du völlig agnostisch davon arbeiten,

Das kann ich auch, schließlich ist ein Serializer auch nichts weiter als eine Möglichkeit zur Datenabstraktion, nämlich für den Transport zum Erzeugen von Sequenzen.

ob die Daten textlich oder binär weiterverarbeitet werden.

Eine mit textlichen Mitteln vorgenommene Serialisierung berührt den Layer Darstellung, im Fall JSON gar ist Code das Mittel für den Transport. Eine Low-Level-Serialisierung jedoch findet auf Byte-Ebene statt, dieser Layer hat weder mit Datentypen noch mit Zeichen noch mit Code oder anderen Inhalten zu tun.

Schließlich haben sich die Entwickler des OSI-Referenzmodells auch was dabei gedacht.

Hast Du Dir meine Beispiele mal angeguckt, wie einfach das letztendlich wird, Texte zusammen mit Binärdaten per HTTP zu übertragen? Wenn ich das mit herkömmlichen "Standards" machen müsste, wirds wesentlich komplizierter. Und genau das ist das Ziel meiner Entwicklungen.

Diese Verantwortlichkeit bleibt ganz alleine bei dem Kodierungs-Algorithmus liegen.

Ja klar, wo denn sonst ;)

Das nennt sich Seperation of Concerns.

Eine Doktorarbeit könnte ich auch schreiben. Ich bin aber eher der Praktiker.

Interessant wird eine Low-Level-Serialisierung

Du bist nicht Low-Level. Du argumentierst ja gerade für eine höhere Software-Schicht, ich argumentiere dagegen.

Nein eben nicht, siehe weiter oben. Ein herkömmlicher Parser nimmt den Parameter-String (oder die POST Daten) komplett in den Hauptspeicher um ihn in die Einzelteile zu zerlegen. Bei multipart/form-data wird, sofern die Komponente den file-Parameter drin hat, eine temp. Datei angelegt. Das kostet CPU, IO und RAM.

Ein Low-Level-Serializer hingegen verzichtet auf rechenintensive Stringoperationen, er erzeugt für Längenangaben Bytes (JS: ArrayBuffer, DataView) oder liest Bytes (PHP, Perl: pack, unpack). Die Bytes der Nutzdaten werden entweder aus einem Handle gelesen oder in ein Handle geschrieben. Während der Übertragung ist das Handle ein Socket, am Server angekommen, ist es STDIN. Von Perl oder PHP ausgehend ist es dann STDOUT in Richtung Webserver und dann wieder das Socket (bitte nicht verwechseln mit Websocket).

das ist CPU- und RAM-gefällig und verzichtet auf temporäre Dateien (Siehe auch meine diesbez. Sicherheitsbetrachtungen).

Mit solchen Performanz-Aussagen musst du vorsichtig sein, hast du Benchmarks oder theoretische Erörterungen darüber, die dir das bescheinigen?

Ich stelle zunächst nur Überlegungen erster Ordnung an und freue mich darüber, dass moderne Browser mit Binärdaten umgehen können. Btw. alle Inhalte meiner Website (370 HTML-Seiten) liegen ebenfalls in einer Binärdatei. Hier gehts nicht um den Transport sondern um Persistenz, aber der Algorithmus ist derselbe um neue Seiten da einzutragen (das läuft bei mir über einen Webservice) oder Einzelseiten da wieder rauszuholen, was bei jedem Request passiert. Da stelle ich auch ohne Benchmark fest, dass die ganze Datei (ca 1MB) schneller ausgelesen, als eine DB-Connection hergestellt ist. Aber auch dieser Layer ist austauschbar, eine Zeile Code ;)

Und fürs performante Auslesen meiner Routingtable habe ich mir was ganz besonderes einfallen lassen: Die liegt als Binary direkt in einem Perlmodul und wird mit use eingebunden.

Außerdem ist Performanz häufig ein Ziel, das im Widerspruch zu einer guten Software-Architektur steht. Deswegen ist es häufig so, dass man Leistungs-Optimierung nicht auf Verdacht betreibt, sondern indem man die Software auf Flaschenhälse analysiert und dann zielgerichtet optimiert, wo Bedarf besteht.

Es ist immer eine Gratwanderung zwischen CPU, IO und RAM.

Des Weiteren benötigen Binärsequenzen weniger Bandbreite als vergleichbare Datenmengen die mit textlichen Mitteln strukturiert sind.

Wie gesagt, das ist kein exklusiver Vorteil von deinem Lösungsansatz. Das haben wir schon alles umsonst, wenn wir einfach so wenig wie möglich machen.

Vollkommen richtig, das sind wir uns einig. Siehe weiter oben und meine schönen Beispiele.

Es ist nie zu spät über neue Techniken nachzudenken, sich darüber auszutauschen und auch mal was Neues auszuprobieren.

Das sage ich auch nicht, ich demonstriere gerade glaube ich sehr genau das Gegenteil, indem ich mich hier mit dir austausche ;)

Dann gib Dich doch mal zu erkennen und ich hoffe das bleibt dabei ;)

Wie gesagt, alles nur Hobby. Hätte ich einen Job, fehlte mir dafür die Zeit. Andererseits bedeutet die Arbeit (Hobby) mit meinem Framework mittlerweile einen beträchtlichen Zeitgewinn, da sind neue Anwendungen ratz fatz entwickelt. Dieses FW ist letztendlich auch nur das Ergebnis meiner beruflichen Praxis und aus diesen Erfahrungen heraus behaupte ich, dass eine Firma, die mit diesem FW entwickeln würde, mit demselben Programmiererpotential mindestens dreimal soviel Aufträge annehmen könnte.

So habe ich mein FW auch mal in einer Firma eingesetzt um einen Fehler zu finden, den andere Programmierer nach Wochen nicht gefunden haben, obwohls ihn selbst da reinprogrammiert hatten. Mit meinem FW war das eine halbe Stunde Arbeit.

Schöne Grüße :)

PS: Respekt vorm Alter erwarte ich nicht, die 58 siehst Du mir ohnehin nicht an ;)