QGIS Server Plugins
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 119 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/67698 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Version <Informatik>CodeAlgorithmServer (computing)DesktopSoftware repositoryPlug-in (computing)Witt algebraPlug-in (computing)TypCache (computing)Service (economics)Polymorphism (materials science)Computer fileZugriffObject (grammar)Digital filterServer (computing)Version <Informatik>CodeDesktopFunktionalitätC++Anbindung <Informatik>FRAMEWORK <Programm>Software repositoryRepository (publishing)Game controllerDifferent (Kate Ryan album)Type theoryFlow separationInterface (computing)Similarity (geometry)Parameter (computer programming)Presentation of a groupLink (knot theory)Functional (mathematics)Connected spaceSoftware frameworkComputer filePoint (geometry)Dependent and independent variablesComplete metric spaceRevision controlBlogProjective planeVideo gameSoftware developerMathematicsOffice suiteCartesian coordinate systemLecture/ConferenceJSONComputer animation
08:24
Term (mathematics)String (computer science)Cartesian coordinate systemCASE <Informatik>Attribute grammarObject (grammar)Web 2.0Projective planeComponent-based software engineeringComputer filePolygonMathematical optimizationData managementLevel (video gaming)Parameter (computer programming)Cache (computing)HistogramFunction (mathematics)Client (computing)Server (computing)MereologyBitBuffer solutionLogicPlug-in (computing)Symbol tableSheaf (mathematics)Sound effectDigital watermarkingInstance (computer science)Filter <Stochastik>Frequency distributionCase moddingNumberInformationProcess (computing)Default (computer science)Integrated development environmentDifferent (Kate Ryan album)Raster graphicsHookingType theoryLogic gateService (economics)ResultantPoint (geometry)File formatData structureStreaming mediaDatabaseSmart cardEigenvalues and eigenvectorsSlide ruleMilitary operationProcess (computing)Computer animationJSON
16:40
Computer wormPlug-in (computing)String (computer science)DesktopServer (computing)Source codeCache (computing)Workplace ShellFeedbackGrand Unified TheoryBerechnungService (economics)FunktionalitätTypQuery languageDebuggerQuery languageVariable (mathematics)System callClient (computing)Projective planeMessage passingWritingPresentation of a groupOperator (mathematics)BitGoogolSoftware frameworkWeb 2.0Level (video gaming)Computer fileEqualiser (mathematics)VolumenvisualisierungAsynchronous Transfer ModeLine (geometry)LogicType theoryMultiplication signFunction (mathematics)Scripting languageJava appletStandard deviationoutputSet (mathematics)Overhead (computing)Buffer solutionCalculationJSONComputer animationLecture/Conference
Transcript: German(auto-generated)
00:07
Ja, hallo und herzlich willkommen zum nächsten Vortrag. Ich freue mich sehr, den Dr. Marco Hugen Tobler aus der Schweiz jetzt hier begrüßen zu dürfen. Und wenn wir ehrlich sind, wären wir jetzt nicht hier zum Kogis Server Vortragsblock. Wenn der Marco nicht 2006 das Projekt ins
00:23
Leben gerufen hätte, da hattest du ein Forschungsprojekt und hast mit der Entwicklung begonnen. Und wir sind jetzt gespannt, was du zu Kogis Server Plugins berichten kannst.
00:42
So gut. Okay, ja, ich freue mich, euch hier begrüßen zu dürfen. Und ich freue mich auch, dass es ein Thema ist, Kogis Server, das offensichtlich auch nach den vielen Jahren noch auf großes Interesse schlößt. Ja, ich arbeite bei der Firma SourcePool in Zürich. Ich starte mit einer Firmenvorstellung, einer etwas unüblichen Firmenvorstellung.
01:04
Und zwar dachte ich, es ist ja das Jahr 2024. Da schreibe ich das nicht mehr selber, im Jahr 2024, da gibt es ja die KI, die kann das für mich machen. Und weil unsere Firma natürlich richtig gut darin vorkommen soll, habe ich gesagt, GPT, schreibe mir bitte ein Loblied auf die Firma SourcePool. Besonders gut gefällt mir da der Satz,
01:29
wo wir da in unseren Büros im Rhythmus der Algorithmen herumtanzen. So, genug.
01:42
Genug Spaß und fertig KI. Kogis Server Plugins. Wieso ein Vortrag über Kogis Server Plugins? Kogis Server Plugins sind nicht wirklich neu, es gibt sie seit 2015 und sie sind auch sehr
02:00
gut dokumentiert. Ich habe da die Links zum Manual und zum Cookbook. Dort steht wirklich fast alles drin, was man wissen muss. Aber mir scheint, die Plugins sind sehr wenig bekannt und darum dachte ich, mache ich einen Vortrag, wo ich die Plugins vorstelle. Vielleicht zur Bekanntheit, also Desktop Plugins in Kogis, habe ich da auf
02:24
dem Repository geschaut und das gibt es über 2000 veröffentlichte Desktop Plugins, hingegen veröffentlichte Server Plugins gibt es nur 11 und die Hälfte davon läuft nicht mehr auf Kogis 3 oder ist outdated usw. Darum dachte ich, mit einem Vortrag kann ich das
02:45
ändern. Wenngleich ich sagen muss, dass viele Plugins sehr spezifisch sind und in Wirklichkeit existieren mehr Plugins da draußen, aber sind halt nicht veröffentlicht. Genau der Vorteil von Kogis Server Plugins, die sind in Python normalerweise geschrieben,
03:06
es ist halt sehr gut, man kann spezifische Anforderungen abdecken, die man halt nur in der Firma selber hat und ein wesentlicher Vorteil, weshalb ich auch in letzter Zeit viele Python Plugins für Kogis Servers mache, ist halt, weil man muss nicht immer auf
03:22
den nächsten Release warten und hat die Funktionalität sofort und wenn ich jetzt etwas in den Core commiten würde, dann geht es dort rein und dann kommt die nächste Version und bis dann die nächste ältere Version kommt, ist dann einige Monate spät usw. Darum kann auch dies sehr gut abgedeckt werden. Genau, also Kogis
03:48
Server Python Plugins sind vom Prinzip her vergleichbar mit den Desktop Plugins, also Kogis Server ist dann C++ geschrieben mit der Qt Bibliothek und die Python Anbindung geht auch da über dieses PyQt Framework. Als Entwickler kann man das
04:06
auch ziemlich ähnlich benutzen, also die wesentlichen Unterschiede sind hier, in der metadata.txt Datei muss man Server gleich true schreiben, weil sonst ignoriert der Server beim Startup, wenn das nicht steht, genau. Und ein weiterer Unterschied,
04:22
also im Kogis Desktop Plugin bekommen wir also ein Kogis Interface-Objekt, wo man dann Zugriff auf alle wesentlichen Dinge hat im Desktop und bei Server Plugins gibt es dieses Kogis Server Interface-Objekt, das eine ähnliche Rolle einnimmt, aber natürlich andere Methoden hat. Also z. B. kann das
04:40
Plugin da über die Methode Request Handler des Interface-Objektes kann es ein Request Handler Objekt anfragen und diesem Request Handler Objekt steht dann stehen da die Anfrageparameter und man kann die Antwort setzen und so weiter. Genau. Andere wichtige Methoden sind z. B. kann man die Service
05:02
Registry, die kann man auch anfragen, das sehen wir dann später, wieso das wichtig sein kann. Wir können einige Objekte registrieren, die wir im Plugin entwickeln, z. B. diese Filtern sehen wir auch noch später. Ja und der Access Control ist auch ein Filter und der Server Cache auch. Genau und da
05:25
sind wir schon bei den verschiedenen Typen von Server Plugins, die es gibt. Also generell muss ich noch sagen, wenn man Python mit Kogis Server verwendet, es ist auch möglich, ich spreche jetzt hier nur über die Plugins, es ist aber ohne weiters auch möglich, alle Kogis Server-Objekte von
05:44
Python aus anzusprechen, das muss nicht unbedingt ein Plugin sein, also kann z. B. auch einen Flask Service in Python schreiben und dort die Kogis Server- Objekte benutzen und dann die machen lassen und die Antwort nehmen und wieder was damit machen. Das ist auch möglich, das wäre dann wie eine
06:02
Standalone-Applikation. Jetzt aber zu den Plugins, da gibt es verschiedene Typen, also die Filter Plugins, z. B. die Filter Plugins und der IO Filter ist wahrscheinlich das häufigste Server Plugin. Bei den
06:24
Filter Plugins, da hat das Plugin Einsprungspunkte und die werden dann so im Workflow an verschiedenen Orten aufgerufen, dort kann dann der Python Code benutzt werden. Also beim IO Filter, üblicherweise hat
06:41
man einen Einsprungspunkt am Anfang, wir kommen noch auf die Details am Anfang, dann am Schluss und dann kann man so die Anfrage annehmen und kann dort was ändern und wenn die Antwort kommt, der Server seine Arbeit gemacht hat, kann man auch die Antwort noch etwas modifizieren. Das ist
07:00
der häufigste Typ von Plugin, dann gibt es da diese Access Control Filter, da gehe ich auch noch drauf ein, da kann man so, wenn man das mit Zugangsrechten machen muss, kann man das verwenden oder wenn man den Cache beeinflussen möchte, dann kann man so einen Cache Filter Plugin machen. Weiter wichtiger Typ ist, wenn man einen eigenen Service schreibt, also
07:23
man macht keine Modifikation für WMS, WFS, WCS und so weiter, dann sagt man, ich habe einen neuen Service, My Service und der gibt etwas zurück, dann kann ich den auch als Plugin schreiben und bei Kugis registrieren, beim Kugis Server, genau
07:41
und man kann auch in einem Plugin verschiedene Dinge mischen, also man kann auch in einem Plugin einen Filter definieren und einen Service registrieren, das geht auch. Genau, hier habe ich so ein Schema gemacht, so wenn so ein Workflow des Servers passiert, da gehe ich vielleicht
08:06
drauf ein, beim Filter IO Plugin, also wenn ich ein Filter IO Plugin schreibe, dann gibt es diese Einsprungspunkte hier und Request Ready und Send Response und Response Complete und das ist jetzt eigentlich die einzige Neuigkeit in
08:24
einem Vortrag, ab 03.38 gibt es auch ein On-Project-Ready und wir sehen jetzt mal da bei diesem Schema, wo das zum Tragen kommt, gibt es einen Pointer, genau also
08:47
wir fangen hier mal an, der Kugis Server, der läuft üblicherweise als Fast und wird meistens von einem Web-Server aus angesprochen, also der Apache, was
09:02
ModFCG startet, selbstständig zum Beispiel eine Anzahl von Kugis Server Prozessen und leitet das dann an diesen Server weiter. Genau und hier sehen wir, wenn der Server aufstartet, dann initialisiert er zuerst mal da die Python, later die Python Plugins, die müssen an einem, entweder an die
09:24
Podort abgelegt werden oder man kann es mit Umgebungsvariable dem Kugis Server sagen, wo die Python Plugins sind. Genau und hier jetzt der Kugis Server, der ist immer am Laufen, aus Performance Gründen, fast CGI und wartet dann laufend auf Anfragen an, das ist Unterschied zum normalen CGI, wo halt
09:42
immer bei jedem Aufruf gestartet wird, das ist viel langsamer. Genau und jetzt kommt da dieser Request Teil vom Client F CGI Accept und wir sehen hier wird zum ersten Mal onRequestReady aufgerufen, also wenn der Anfrager bereit ist, wie der Name sagt, dann werden alle registrierten
10:03
Serverfilter aufgerufen und können dann etwas in dieser Methode machen mit Python Code, also die Anfrage verändern üblicherweise. Genau und dann initialisiert Kugis Server das Projekt, also schaut, welches Projekt wird genau angefragt, gibt ja etwas eine Logik dazu und es ist dann gesetzt.
10:26
Genau, jetzt die Sache ist, bis vor 3.38 gab es nur onRequestReady und nicht onProjectReady, tatsächlich möchte man aber oft onProjectReady verwenden, weil man möchte zum Beispiel, wenn man irgendetwas am Projekt
10:42
ändern möchte, zum Beispiel möchte einen einen Layer dynamisch ändern oder eine Layer-Symbolisierung dynamisch ändern, dann kann man eigentlich nur auf das Projekt zugreifen, wenn es auch initialisiert ist im Server, also dann kann man über QS Project Instance normal auf das Projekt zugreifen und
11:01
darum ist das häufig die Methode, die man eigentlich möchte und onRequestReady ist nicht ganz obsolet, weil wenn man zum Beispiel in der Anfrage den Map-Parameter ändern möchte, dann müsste man das vorher machen, bevor Kugis Server das Projekt initialisiert. Und jetzt ohne dieses onProjectReady
11:21
musste man halt oft dieses Cache-Objekt von Kugis Server herausfinden, was ist denn für ein Projekt-File, das Projekt-File kann ja verschieden sein und auch SLD übersteuert sein und in der Datenbank und so, also muss man herausfinden, was ist da angefragt und dann den Project-Cache angreifen und dann dort schauen, ist das schon gecasht und wenn es
11:43
gecasht ist, nimm es raus und modifiziere es und sonst steige es rein. Genau, also es hat sich verbessert. Genau und dann kommen wir da weiter, wird der Kugis Server schaut dann, was wird für einen Service angefragt und ruft die Methode ExecuteRequest auf. Genau, es kommt die Antwort, das
12:06
Resultat und hier gibt es einen weiteren Einsprungspunkt onResponseComplete, das ist sehr praktisch, wenn man halt die Ausgabe ändern möchte, zum Beispiel ein neues Ausgabeformat oder getFeatureInfo anders
12:21
strukturieren und so weiter, kann man das dort machen. Genau, genau, dieses onSendResponse fragt ihr euch vielleicht, wieso gibt es onResponseComplete und onSendResponse. Es gibt der WFS zum Beispiel, der streamt die
12:46
Bilder aus auf einmal, aber der WFS, der sammelt nicht alle Daten und gibt sie erst mal raus, weil dann müssten alle im Speicher sein, sondern er gibt sie so portionenweise raus und wenn man dort reinhucken möchte, dann ist eben dieses onSendResponse die bessere Wahl. Genau, ja, Filter dann, einige
13:11
Beispiele, habe ich gesagt, modifizierte getFeatureInfo-Antwort, sehr beliebt ist auch, wenn der Client jetzt zusätzliche Informationen braucht, die halt nicht drin sind, dann kann man das in den Output von getProjectSettings
13:25
schreiben, weil getProjectSettings ist ja nicht standardisiert, getCapabilities ist es und in getProjectSettings kann man dann halt irgendwas reinschreiben und der Client kann das, kann das die Informationen dann auswerten. Zum Beispiel wäre, zum Beispiel wenn ein Client ein Rasterhistogramm oder eine Häufigkeitsverteilung braucht, um
13:44
einen Slider anzuzeigen oder ein Histogramm, dann könnte das zum Beispiel dort reingehen, genau. Anderes Beispiel, das ich gemacht habe, ist geotiff-output für getMap, also wird der Output genommen und dann wird noch die Georeferenzierung da gedalmäßig reingeschrieben, das kann man auch
14:03
machen. Genau, dann auch sehr beliebt ist, wenn man jetzt, viele Clients fragen teils schon mit Buffer ab und schneiden dann selber ab, wenn man einen Client hat, der das nicht macht, könnte man im Plugin zum Beispiel beim
14:21
OnRequestReady einen größeren Ausschnitt anfragen und dann, wenn die Anfrage durch ist, kann man, kann man es wieder abschneiden, das ist so, um so Randeffekte bei Label und Punkten zu vermeiden. Genau, oder man kann auch einen Watermark auf Karten zeichnen, es gibt mehrere Möglichkeiten das zu machen, aber wenn man es jetzt forcieren muss, dann kann man zum
14:42
Beispiel einen Plugin machen. Genau, die AxisControl Filter Plugins sind etwas exotischer, ich habe jetzt ehrlich gesagt auch noch keine Anwendung gesehen. Der Anwendungsfall ist, man hat halt, muss so Layer- und Attribut-
15:05
Permissions durchsetzen, jetzt ist das so, man macht das häufig, nur noch mit der Applikation oder im Web-Server, sobald aber die geografische
15:23
Komponente reinkommt, dann ist es praktisch, wenn man es im Server selber macht, zum Beispiel das Plugin, zum Beispiel, wenn man sagt, ja Benutzer, ah darf ich diesen Polygon nicht modifizieren oder in diesem Polygon nicht sehen oder nur mein Polygon und so, sobald was
15:40
geografisch zu sehen ist, ist es halt viel besser, wenn es im Server selber ist und darum gibt es da diese Hooks, also und zwar muss das Plugin dann diese Methoden implementieren, also kann dann zum Beispiel mein Layer Permission sagen, also das Plugin muss selber die Autofizierung Benutzerverwaltung machen, aber kann dann bei der Methode Layer Permissions zum Beispiel sagen,
16:01
nein darf es nicht und dann gibt es falls zurück und dann kann der Benutzer das auch nicht sehen, genau, und auch bei den Attributen und Weiteres exotisches Plugin Art ist dieses Cache Filter Plugin, dort können Cache Operationen überschrieben werden, als zum Beispiel den Gate Capabilities
16:26
kann man, Cache kann man modifizieren, Gate Legend Graphic Cache und im WMTS kann man auch, wenn ein Teil angefragt wird, also kann man selber die eigene Cache Logik implementieren, wenn ich mich richtig erinnere, in WMTS
16:41
gibt es sogar keinen eigenen Cache und man muss so ein Plugin schreiben, wenn man es gecached haben möchte, genau, ein weiterer Typ ist, dass man einen neuen Service als Plugin schreibt, dazu leitet man eine Unterklasse von Google Service ab und registriert die und implementiert die Methode ExecuteRequest
17:01
und dort kann man dann alles implementieren, was man möchte, also wir sehen das da auf diesem Schema, genau, also alles was dann hinten dran passiert, macht dann das Plugin selber und der Google Server kommt dann nicht, macht dann dort nichts mehr, genau, was kann man damit tolles machen, es gibt
17:30
sein Plugin im Repository, damit kann man ein GeoJSON-File renderen und gibt dann Service-Gleich-Render GeoJSON an, man
17:40
könnte zum Beispiel den Cache-Management in einem solchen Plugin und sagen, mach eine Operation, die sagt, lösche alle Projekte aus dem Cache oder bestimmte oder genau, man kann auch eigene Capabilities zurückgeben,
18:01
man könnte auch zum Beispiel, es gab früher ein Plugin, das einen WPS implementierte als Kugi-Server-Plugin, das ist etwas veraltet, mittlerweile gibt es ein neues Projekt und dort wird aber dann Kugi-Server von einem Python-Service angesprochen, ist dann also kein Plugin mehr, genau, noch ein kleines Side-Thema, die Backen von Server-Plugins
18:28
ist ja immer etwas mühsam, wenn man Plugin entwickeln möchte, meistens macht es nicht, was man möchte oder nicht sofort und was kann man da machen, im Kugis Desktop verwende ich häufig da dieses First Aid-Plugin,
18:41
das ein sehr komfortabler Debugger ist, mit grafischer Benutzerschnittstelle, im Server kann ich das natürlich nicht verwenden, das ist sehr schade, was kann man machen, basic, die meisten schreiben halt mit Kugis Message-Log, schreiben sie etwas ins Message-Log, hallo, wer ist so und so, ist natürlich mühsam, was ich häufig mache, ist da dieses Intermediate,
19:05
ich brauche diesen PDB, diesen Python-Debugger und setze dann den Query String als Umgebungsvariable und dann kann ich den Kugis-Server auf der Kommandozeile aufrufen und dann, wenn PDB startet, dann kann ich
19:25
dort damit die Sachen ausprinten, das ist dann eigentlich ein guter, ja, ist so wie GDB, ja, genau, also ist eigentlich eine gute Möglichkeit, Nachteil ist halt, der Quellcode muss etwas verändert werden, man muss einen Aufruf reinschreiben, wo der PDB dann stoppen soll und wo man
19:46
dann anfangen kann, debuggen, aber das ist eine Linie, das ist nicht sehr, sehr tragisch, genau, Advanced wäre, das habe ich jetzt noch nie gemacht, das gibt Leute, die debuggen Kugis-Plugin mit einem Remote-Debugger-Plugin,
20:01
das dann einen Debug-Client startet und in der Idee ist, dann ein Debug-Server und die kommunizieren dann miteinander, was sicher sehr gut und mächtig ist und so, aber ist halt etwas overhead und Nachteil ist halt, der Quellcode müsste noch mehr modifiziert werden, man müsste dann
20:22
in diesen Debug-Client starten, ja, gut, das wäre meine kleine Einführung gewesen, vielen Dank für die Aufmerksamkeit und ich freue mich auf Fragen und Rückmeldungen. Ja, herzlichen Dank an dich, Marco, es gibt
20:48
auch ein paar Fragen, es können auch noch weitere gestellt werden, du hattest das Get-Map-Buffer-Plugin vorgestellt und gibt es das erwähnte Plugin irgendwo als Open Source? Ich habe das nicht veröffentlicht, aber es spricht
21:03
eigentlich nichts dagegen. Ja, und du hast ja jetzt einiges vorgestellt, also würdest du die Ideen auch der Plugin-Lösung auch veröffentlichen? Ja, ich denke, das spricht nichts dagegen, es war eher Faulheit, dass ich es nicht gemacht habe. Ah ja, genau, weil da ist bestimmt Interesse. Gut, dann ist hier eine
21:23
Frage, können auch QGIS-Klein-Plugins einfach in einem QGIS-Server integriert werden, um zum Beispiel einige Berechnungen genierischen, einige Berechnungen, als generischen Service über eine standardisierte API zur Verfügung zu stellen? Also ja, das ist eine gute Frage, generell
21:42
muss ein Plugin nicht ein Desktop oder ein Server-Plugin sein, es kann auch beides sein, muss natürlich auch beide Einsprungspunkte implementieren, aber es gibt auch Beispiele, wo zum Beispiel da gibt es ein Desktop-Plugin, um die Einstellungen zu setzen und die Einstellungen werden dann im Server sozusagen gebraucht oder werden ins Projektfall geschrieben und im
22:04
Server-Plugin werden die dann ausgelesen und verwertet, dass man kann ein Plugin machen, dass beides zugleich ist. Okay, danke. Ja, hier sind jetzt keine Fragen mehr, sind vielleicht noch Fragen hier im Raum, die ihr stellen möchtet?
22:23
Gut, das sieht jetzt erstmal nicht so aus. Ich habe noch eine. Zum Debuggen, kann man das auch im QGIS-Creator debuggen, so wie den QGIS-Deskop ja eben auch? Ja, den QGIS-Server selber schon, also QGIS-Creator ist super zum C++-Debuggen,
22:41
also den QGIS-Server kann man schon im QGIS-Creator debuggen, einfach die Python-Plugins halt nicht. Ja, sonst noch Fragen? Ja, das sieht... ach, hier vorne ist noch eine. Ich kann noch eine Frage stellen. Genau dort ist die In- und Output-Plugins
23:02
erwähnt und im Vortrag davor haben wir ja auch diesen kleinen Mini-Proxy gesehen, der quasi vor dem QGIS-Server setzt. Kannst du was dazu sagen, was, warum sinnvoller ist? Also meine erste Idee wäre jetzt auch gewesen, wenn ich eine Änderung vom In- oder Output haben möchte, dass ich keinen Plugin schreibe,
23:21
sondern einfach einen Python- oder PHP-Script oder Java davor setze, was dann den geänderten Request weiterleitet. Das Plugin würde ja ein bisschen anders arbeiten und was würdest du da bevorzugen und warum? Also wir brauchen meistens, brauchen wir das Rewriting vom Web-Server oder zum Beispiel
23:42
Apache-Mode-Rewrite, um die URL gegen außen zu verstecken. Das ist eigentlich der einfachste Weg, weil man kann es in Apache-File in ein oder zwei Zeilen kann man das machen. Das braucht am wenigsten Arbeit. Der Vorteil, wenn man es jetzt über das Plugin machen möchte, der Vorteil ist halt, man kann dort noch mehr, wenn man jetzt eine sehr komplizierte Logik hat,
24:04
die man nicht mit einem simplen Text-Replay im Rewriting machen kann, dann wäre das ein Vorteil auch. Danke. Ja, wir hatten noch Zeit für eine Frage, falls noch jemand?
24:22
Ja, die kommt dann von mir. Bietet der Kugis Server irgendwelche Dashboard-Funktionalitäten? Also ich sehe, wie stark der genutzt wird, welche Services da von Nutzern abgefragt werden? Der Kugis Server bietet diese Funktionalität nicht, aber ich denke, es gibt genügend bestehende Frameworks, die das auf Web-Server-Ebene dann machen.
24:47
Gut, dann nochmal herzlichen Dank an dich, Varko, für den Vortrag.