Moinsen @chriddi und @steemchiller.
Danke für deinen Kommentar zu meinem Hilfeschrei, @chriddi. Es wäre durchaus wünschenswert, wären weitere Entwickler an dem Gegenstand interessiert. Schließlich gehören sie zu einer der gefragtesten Zielgruppen des SteemWiki. Danke @steemchiller, du hast mir schon wieder elementare Denkansätze vermittelt. Ich versuche, das hier vor gemischtem Publikum zu rekapitulieren, zu erweitern, bzw. zu diskutieren. Das dient dem tieferen Verständnis bei jedem Beteiligten, geht es hier doch um die Essenz von Funktionen und ihren Libraries. Worüber ich zur Findung einer verbindlichen Architektur komme. Daher wage ich, dich kurz weiter zu beanspruchen, Chiller.

Der Umgang mit den Schlüsseln ist unsere Archillesferse. Manche Prozesse wollen den Posting Key, manche brauchen den Active Key, usw.. Wir wollen unsere Schlüssel aber nicht durch das Internet zu einem Node schicken, nur damit dort ein Server klärt, ob auf die Blockchain geschreiben werden darf, oder nicht. Oder ob wir für die Info berechtigt sind, die angefordert wurde. Bei PHP geht das ausschließlich über Versenden des Schlüssels, was der Beliebigkeit sehr nahe kommt, sicherheitstechnisch überspitzt ausgedrückt. Ferner hast du keine Ahnung, was der Empfänger-Node (dnode,ist eine Maschine, Software und ein Betreiber) mit deinem Schlüssel noch veranstaltet. Auf dem Wege begibst du dich in vertrauenswürdige Hände, was einem Ausgeliefertsein entspricht. Es gibt daher mindestens zwei Argumente gegen den Einsatz von PHP-Libraries, bei der Kommunikation mit der Blockchain.

Keine Schlüssel senden

Das ist das eine Problem und die Chiller-Methode ist mit JS-Abfragen eindeutig im Vorteil. Eine gewünschte Transaktion ruht dabei so lange im lokalen Browsercache, bis dem wartenden Clearingprozess der richtige Schlüssel vorliegt. Dem Dienst an der JS-API des Servers ist es dabei gleich, was der User darf und was nicht. Deine Berechtigung wird lokal geklärt, vorher kannst du die Daten nicht anrühren. Du bräuchtest Hacker-Methoden, sie zu lesen, bzw. ausführen zu lassen. Ohne Schlüssel ist das nahezu unmöglich. Wir schicken ausschließlich Nutzdaten über das Netz und keine Schlüssel. An denen hängt bekanntlich alles Glück und Gut der Miner, wie auch für jeden Steem-Autoren sein Copyright. Man könnte JS daher zum Dogma erheben.

B) Geschwindigkeit und PHP

Es würde sich im Falle eines PHP-Nodes um den sogenannten dnode handeln, auf dem eine dnode-Library den Verkehr regelt. Die wird abgefragt von einem dnode Client (User). Nach dem Prinzip hatte @jesta seine genialen Steemtools in PHP entwickelt. Unvergessen die Zeit, die sie bei der Ausführung in Anspruch nahmen! Deren Haupteinsatz ist in 2016/17 zu verorten, also lange vor dem Auftauchen von Chillers lockeren Javascriptmethoden. Jestas Tools waren die einzige Quelle für tiefergehende Bockchainabfragen. Dafür gab es keine, oder nur unzulängliche Steemit-Methoden. Die Steemtools waren vor allem sehr langsam. Erinnert ihr euch?

Javascript vs. PHP?

Das erkläre mal auf diplomatischen Weg einer Kultur, für die Javascript der Beelzebub ist und wo der Chef nach der besten PHP-Library fragt. JS gilt als unsicher nicht parallel genug (es arbeitet strikt sequenziell) und ist selbst von Script-deppen wie mir zu benutzen. Ich frage mich wiederholt, warum ein Frosch so einen Stoff überhaupt andenken muss, aber es ist seine Vision und seine Aufgabe, sein Tiki durchzuziehen. Solange kein Besserer am Thema arbeitet muss er eben ran. Sag an, lieber @steemchiller: Habe ich das gerade richtig rekapituliert?

Es gibt Bedenken

Nach meinen Informationen hat Jesta den eigenen dnode abgeschaltet. @dragosroua entwickelt sein PHP nicht weiter und überhaupt, die angebotenen Libraries sind alle alt bis auf die Lösungen, wo überwiegend statistische Daten von der Blockchain verarbeitet werden. Wie das mit der sicher tollen PHP-Library von @t3ran13 der Fall ist. Ansonsten tut sich bei der Entwicklung von PHP-Libraries derzeit nicht viel und die schlüsselhöheren Abfragen, bzw Aufträge müssen eventuell sogar über sie ausgeführt (Coin-Transfer etc.) werden. Da weiß ich noch zu wenig. Nach meinem Glauben geht nahezu alles auch über die JS-API. Arbeitest du an solchen Stellen mit PHP, Chiller? Das Fachgespräch ist für mich noch nicht zuende,

Die Wand

Die PHP-Leute glauben nicht an die Harmlosigkeit von JS. Sie trauen Javascript nicht über den Weg und Firmen lassen gar Javascript netzwerkweit abschalten. Das ist Fakt. Wir haben eine Diskrepanz zwischen bspw. Redaktionen und privaten Anwendern, die man nicht einfach vom Tisch wischen kann. Danach entsteht ein Zusammenhang mit den Zielen des Tikis, der eindeutig für den Einsatz von PHP spricht. Will doch das SteemWiki die Brücke von der Blockchain zu den Unternehmen der Medienbranche schlagen.

Muss ich in dem Fall einen Steem SQL-Node betreiben, wie du das ja auch tust, Chiller? Firmen wollen kein Javascript und hier beißt sich die Schlange in den Schwanz. Oder etwa nicht? Redaktionen müssen ihren Content massenweise und geordnet auf die Blockchain bringen. JS geht bei denen nicht. Mit welcher Library geht das am besten? Ich überlege, ob nicht ein Transfer vom PHP der Unternehmensrechner zum JS der API im Tiki selbst statt finden kann. Corporated PHP wird vom Tiki als API-Javascript weiter gegeben und umgekehrt. Wäre das ein Ansatz?