Feedback und Vorschläge zur STS Plugin-API
Verfasst: Di Aug 15, 2023 1:32 am
Hallo,
ich habe mich in letzter Zeit etwas mit der Plugin-Entwicklung für den STS auseinandergesetzt und dabei auch die API etwas genauer kennengelernt.
Im Voraus einmal ein großer Dank an die Entwickler hinter dem STS. Ein so großes System am Laufen zu halten und auch noch neue Funktionen hinzuzufügen, ist eine unglaublich schwere Aufgabe. Deshalb: Alles, was ich in diesem Post kritisiere, sollte niemanden persönlich angreifen oder beleidigen. Es sind lediglich meine Meinungen, und ich diskutiere gerne mit allen darüber und beantworte Fragen dazu.
An sich ist die Plugin-API eine coole Sache, jedoch verstehe ich nicht ganz, wieso man diese über eine TCP-Verbindung mit XML gelöst hat. Die meisten Anfragen (ausgenommen von Ereignissen) haben ein typisches Request-Response-Schema: Es kommt eine Anfrage, darauf wird geantwortet.
Über TCP kommt nun die Anfrage, jedoch gibt es keine Möglichkeit, eine Antwort eindeutig der Anfrage zuzuordnen (hier wären vielleicht IDs eine Lösung? Nach dem Prinzip: Das Plugin schickt eine ID mit, der Server antwortet mit derselben ID darauf). Für Ereignisse macht TCP Sinn, jedoch eigentlich auch nur für Ereignisse. Ich würde so etwas über eine REST-Schnittstelle implementieren und die Ereignisse entweder über Web-Sockets oder Server-Sent-Events.
Da ich an der Schnittstelle leider nichts ändern kann, habe ich mich auf den zweiten Teil fokussiert: die Java-Bibliothek. Auch hier gibt es keine Verbindung zwischen der Anfrage und der Antwort. Von irgendwo aus rufe ich die request_zugdetails Methode auf und bekomme dann in der response_zugdetails meine Antwort. Zu welchem Ereignis diese jedoch gehört, davon habe ich keine Ahnung.
Des Weiteren benutzt die Bibliothek einen meiner Meinung nach komischen Denglisch-Mix. request_zugdetails ist weder Deutsch noch Englisch und nebenbei bemerkt auch nicht Java-Convention-konform. Nach denen müsste die Methode nämlich eigentlich requestZugdetails oder noch besser requestTraindetails heißen.
Auch ist das Erweitern durch den PluginClient meiner Meinung nach nicht sinnvoll gelöst. So ein Erweitern würde Sinn machen, wenn der STS das Plugin selbständig lädt (wie bspw. Minecraft). Da er das jedoch nicht tut, wäre eine Lösung mit einer eigenen Klasse, von der einfach eine Instanz erstellt wird, meiner Meinung nach sinnvoller.
Da mir die derzeitige API, wie wahrscheinlich schon bemerkt, nicht wirklich gefällt und ich aber auch weiß, dass eine komplett neue API zu schreiben oder die derzeitige umzuschreiben viel Arbeit wäre, habe ich mich dazu entschlossen, meine eigene API zu schreiben: https://github.com/CheeseTastisch/STSPluginAPI
Ihr dürft diese gerne benutzen. Es fehlen eventuell noch einige Teile, die ich in der derzeitigen API finde, aber beim Durchlesen der Doku-Seite vergessen habe. Diese werde ich in den nächsten Tagen noch ergänzen.
Aber welche Vorteile hat meine API jetzt? Zum einen schafft sie eine eindeutige Zuteilung zwischen der Anfrage und der Antwort. Zum Beispiel gibt die Funktion getPlatforms direkt eine List<Platform> zurück. Um dies zu erreichen, muss jedoch (leider) der Thread blockiert werden. Das ist an sich kein Problem, kann jedoch mit UI schnell zu einem Problem werden. Deshalb gibt es neben der blocking API auch eine completable API, welche mit CompletableFutures arbeitet. Und für diejenigen, die gerne Kotlin benutzen, gibt es auch noch eine suspending API, welche mit Kotlin coroutines arbeitet.
Auch kommt es meine API ohne das Erweitern auszukommen, da einfach eine Instanz einer API-Klasse vom Benutzer erzeugt wird, welche dann benutzt werden kann.
Das war's aber auch schon wieder. Ob ihr jetzt meine API benutzt oder nicht, sei euch freigestellt. Jedoch solltet ihr beachten, dass meine API noch nicht wirklich viel getestet wurde und noch eventuelle Fehler beinhaltet oder neuere Funktionen noch nicht beinhaltet.
Über jegliches Feedback würde ich mich freuen, sowohl positives als auch negatives. Denn nur wenn ich weiß, was an meiner API nicht gut ist, kann ich sie verbessern.
Dementsprechend vielen Dank für eure Kritik und eure Geduld, euch das alles hier durchzulesen, und noch einen schönen Tag,
Lian
ich habe mich in letzter Zeit etwas mit der Plugin-Entwicklung für den STS auseinandergesetzt und dabei auch die API etwas genauer kennengelernt.
Im Voraus einmal ein großer Dank an die Entwickler hinter dem STS. Ein so großes System am Laufen zu halten und auch noch neue Funktionen hinzuzufügen, ist eine unglaublich schwere Aufgabe. Deshalb: Alles, was ich in diesem Post kritisiere, sollte niemanden persönlich angreifen oder beleidigen. Es sind lediglich meine Meinungen, und ich diskutiere gerne mit allen darüber und beantworte Fragen dazu.
An sich ist die Plugin-API eine coole Sache, jedoch verstehe ich nicht ganz, wieso man diese über eine TCP-Verbindung mit XML gelöst hat. Die meisten Anfragen (ausgenommen von Ereignissen) haben ein typisches Request-Response-Schema: Es kommt eine Anfrage, darauf wird geantwortet.
Über TCP kommt nun die Anfrage, jedoch gibt es keine Möglichkeit, eine Antwort eindeutig der Anfrage zuzuordnen (hier wären vielleicht IDs eine Lösung? Nach dem Prinzip: Das Plugin schickt eine ID mit, der Server antwortet mit derselben ID darauf). Für Ereignisse macht TCP Sinn, jedoch eigentlich auch nur für Ereignisse. Ich würde so etwas über eine REST-Schnittstelle implementieren und die Ereignisse entweder über Web-Sockets oder Server-Sent-Events.
Da ich an der Schnittstelle leider nichts ändern kann, habe ich mich auf den zweiten Teil fokussiert: die Java-Bibliothek. Auch hier gibt es keine Verbindung zwischen der Anfrage und der Antwort. Von irgendwo aus rufe ich die request_zugdetails Methode auf und bekomme dann in der response_zugdetails meine Antwort. Zu welchem Ereignis diese jedoch gehört, davon habe ich keine Ahnung.
Des Weiteren benutzt die Bibliothek einen meiner Meinung nach komischen Denglisch-Mix. request_zugdetails ist weder Deutsch noch Englisch und nebenbei bemerkt auch nicht Java-Convention-konform. Nach denen müsste die Methode nämlich eigentlich requestZugdetails oder noch besser requestTraindetails heißen.
Auch ist das Erweitern durch den PluginClient meiner Meinung nach nicht sinnvoll gelöst. So ein Erweitern würde Sinn machen, wenn der STS das Plugin selbständig lädt (wie bspw. Minecraft). Da er das jedoch nicht tut, wäre eine Lösung mit einer eigenen Klasse, von der einfach eine Instanz erstellt wird, meiner Meinung nach sinnvoller.
Da mir die derzeitige API, wie wahrscheinlich schon bemerkt, nicht wirklich gefällt und ich aber auch weiß, dass eine komplett neue API zu schreiben oder die derzeitige umzuschreiben viel Arbeit wäre, habe ich mich dazu entschlossen, meine eigene API zu schreiben: https://github.com/CheeseTastisch/STSPluginAPI
Ihr dürft diese gerne benutzen. Es fehlen eventuell noch einige Teile, die ich in der derzeitigen API finde, aber beim Durchlesen der Doku-Seite vergessen habe. Diese werde ich in den nächsten Tagen noch ergänzen.
Aber welche Vorteile hat meine API jetzt? Zum einen schafft sie eine eindeutige Zuteilung zwischen der Anfrage und der Antwort. Zum Beispiel gibt die Funktion getPlatforms direkt eine List<Platform> zurück. Um dies zu erreichen, muss jedoch (leider) der Thread blockiert werden. Das ist an sich kein Problem, kann jedoch mit UI schnell zu einem Problem werden. Deshalb gibt es neben der blocking API auch eine completable API, welche mit CompletableFutures arbeitet. Und für diejenigen, die gerne Kotlin benutzen, gibt es auch noch eine suspending API, welche mit Kotlin coroutines arbeitet.
Auch kommt es meine API ohne das Erweitern auszukommen, da einfach eine Instanz einer API-Klasse vom Benutzer erzeugt wird, welche dann benutzt werden kann.
Das war's aber auch schon wieder. Ob ihr jetzt meine API benutzt oder nicht, sei euch freigestellt. Jedoch solltet ihr beachten, dass meine API noch nicht wirklich viel getestet wurde und noch eventuelle Fehler beinhaltet oder neuere Funktionen noch nicht beinhaltet.
Über jegliches Feedback würde ich mich freuen, sowohl positives als auch negatives. Denn nur wenn ich weiß, was an meiner API nicht gut ist, kann ich sie verbessern.
Dementsprechend vielen Dank für eure Kritik und eure Geduld, euch das alles hier durchzulesen, und noch einen schönen Tag,
Lian