Achtung - Technikeintrag - vielleicht langweilig.
Es ist mal wieder Zeit fürs Entwickeln da. Da Google sich noch nicht regt, kann ich mich um andere Dinge kümmern.
Ich habe angefangen an einem neuen Major-Update zu arbeiten. Dabei habe ich die angeregten PlugIns im Blick.
Here we go.
Ich hatte im letzten Eintrag geschrieben, dass ich batch so weit stabilisiert habe, dass da eigentlich nichts unerwartetes mehr auftauchen sollte - so Google will.
Also habe ich mich hin gesetzt und gefragt, was die eigentlich Baustelle im Code ist.
Unter der Haube arbeitet batch mit dem Framework VueJS. Damit lassen sich herrlich einfach und fix (quick and dirty) Komponenten für die Oberfläche erstellen. Das habe ich mit Wonne getan ohne aber die Vorteile die dieses Frameworks aus zuspielen. Der Vorteil ist: Man kann eine Menge Code zusammenfassen und wiederverwendbar machen. Hier harkt es bei batch. Ich habe also angefangen die gesamte Oberfläche in kleinste Komponenten zu zerlegen.
Welchen Vorteil hat das?
Nun. Wie gesagt. Am Ende spart man sehr viel Zeit, weil nicht alles immer wieder von neuem geschrieben werden muss. Wir bekommen kleine Codeblöcke, die sich mit einer kleinen Sache beschäftigen, dafür aber überall auftauchen. Für mich bedeutet das, dass ich nur immer diesen einen Codeblock pflegen muss, wenn es in batch ein Problem gibt, und ich dabei alle Stellen in denen dieser Block zum Einsatz kommt mit korrigiere. So weit so klar. Nun kommt aber der weitere Schritt: wenn wir wollen, dass Menschen PlugIns schreiben, wollen sie das auf eine einfache Art tun. Diese Menschen sind dann in der Lage auf all diese Komponenten zu zugreifen und zu nutzen. Damit erhalten wir vor allem auch ein konsistentes Erscheinungsbild und wir können steuern, was eine Plugin darf und was nicht.
Um PlugIns sicher zu machen, habe ich Vorkehrungen getroffen, dass Daten nicht einfach abfließen können. Hierfür habe ich einen Mechanismus eingebaut, der genau regelt, an welche Server Daten geschickt werden können oder von welchen sie empfangen werden dürfen. Das macht das Entwickeln für mich ein bisschen komplizierter, schafft aber zusätzliche Sicherheit.
Der Zugriff auf Daten durch Plugins wird innerhalb von batch auch beschränkt werden. Hierfür habe ich den "Main Prozess" (dieser hat hohe Berechtigungen) stark vom "Render Prozess" (hat geringe Berechtigungen) entkoppelt. Aktuell haben diese Prozesse in batch etwa gleichwertige Berechtigungen. Dies wird potenzielle Szenarien gegenüber denen batch aktuell noch anfällig sein könnte, ausschließen. Vor allem die Gefahr durch präparierte Eingaben wird dann ins Leere laufen.
Der Rendererprozess muss nun aber alle Änderungen im Main Prozess quasi anfragen. Da ist aber noch ein wenig zu tun.
Auch darf der Render-Prozess nicht mehr so einfach auf das Dateisystem zugreifen. Hier gibt es aber noch ein bisschen Arbeit, weil es sich nicht hundert prozentig verhindern lässt, potentiell unsichere Dinge zu zulassen. Das liegt jedoch an dem Tool "Webpack" um das ich so einfach nicht drumherum komme. Da gab es aber heute einen großen Fortschritt. Das bekomme ich noch einigermaßen dicht oder kann es einfach einem Angreifer sehr schwer machen.
Aktuell bin ich gerade also dabei all die Komponenten zu schreiben. Optisch verändert sich wenig. Eher Detailkram. Aber die Komponenten funktionieren viel besser und vor allem zuverlässiger. Ich muss viel weniger hacking betreiben, damit sich alles so verhält, wie es soll. Zudem lasse ich alle Komponenten automatisch durch dokumentieren, damit eventuelle Plugin-Schreiber eine Chance haben.
Ich werde zu gegebener Zeit neue Screenshots veröffentlichen. Das dauert gerade einfach, weil ich batch quasi neu schreibe. Funktionieren tut da noch nichts, aber es ist jeden Tag ein kleiner Fortschritt sichtbar und ich kann alte Designfehler im Code korrigieren.
batch ist mir eine Herzensangelegenheit und wird es wohl auch noch lange bleiben.
The evolution of batch
Liebe Grüße
Benni