.. das ist viel harte Arbeit. Die man mit dummen Bemerkungen mal eben nicht kaputt macht...
das war so nicht beabsichtigt - werd dich nicht weiter stören
Beiträge von zarfld
-
-
Das Kernproblem ist folgendes.... Ich will vermeiden das es von dem Projekt 100 verschiedene Versionen gibt. Das Projekt verfolgt genau eben nicht solches Ziel, sondern ein Core der so flexible ist das ihn Hersteller trotzdem anpassen können ohne meinen Code anzufassen.
Ob als Client ein Browser zum Einsatz kommt ist vollkommen irrelevant.Nochmal wenn die API nicht kennst kann du sie nicht nutzen. Wie willst du wissen welche Seiten man von einen Webserver abrufen kann wenn sie nicht gelistet sind ?
das ist klar und macht ja auch Sinn
Nochmal wenn die API nicht kennst kann du sie nicht nutzen. Wie willst du wissen welche Seiten man von einen Webserver abrufen kann wenn sie nicht gelistet sind ?
ich natürlich nicht - aber der der den Webserver erstellt müsste doch wissen was er gebaut hat bzw oder besser nach welchen Regeln sie sich generisch aufbaut.
oder ist dein Problem dass dies noch nicht klar ist bzw du unsicher bist obs dir passt.
Bitte nicht als Kritik verstehen - ich versuche nur zu folgen bzw. dein Problem zu verstehn.
-
Der Controller generiert die Json, XML oder sonst was aus den Daten der Geräte. Die REST API beschreibt die Ressourcen und dessen Methoden.
Um das ganze zu nutzen musst du ja Kenntnis von der API haben und natürlich auch von AVB. Sonst bist du selbst mit herumprobieren nicht in Stande das Sinnvoll zu nutzen.
nur um zu prüfen ob ichs nun verstanden hab:
also ist das generieren der Json dann doch in "deiner Hand" -> d.H. wenn das System nachdem du das jSon strukturierst kennst müsstest du ja auch den ümgekehrten Weg gehen können.
(jSon und REST hab ich schon kennengelernt - und habs bisher über VB ausgewertet und Objekte entsprechend "befüllt" - da gings aber eher um "Ticketverwaltung" am Servicedesk das war teilweise auch generisch aber folgte einer definierten Struktur ähnlich einem "Objektmodel")
die Daten der Geräte bekommst du über den MRRP der einzelnen Geräte die sich "anmelden" nehme ich an.
Jetzt kommt die Event gesteuerte API, die gibt dir zusätzliche Informationen was du mit diesen Daten machen kannst und welche Elemente des UI zu steuern Sinnvoll sind. Du musst dir das so vorstellen das hinter jeder Tür weitere Türen auftauchen die der Anwender verwenden kann. So treibt sich die API von alleine ! Wenn du etwas änderst verschiebst du nur die Tür und der Client findet schon den weg da er ja den links folgt. Sonst muss du deinen Client Code anpassen, da du sonst gegen die Wand läufst.
als Beispiel für so ein Event: Hallo ich bin ein neuer Talker ich heiße "xxx" kann "y" Kanäle zur Verfügung stellen - als Format kann ich dir x oder z anbieten .....
Entsprechend dieser info willst du/(bzw machst du bereits?) dann deine HTMLSeite aufbauen.
wenn das stimmt hab ich den faden wieder gefunden
-
Alles anzeigen
...
Die schicken Screenshots sind ja dynamisch erzeugter HTML Code auf Basis der im Json zur Verfügung gestellten links.
Das funktioniert auch soweit ganz gut, kommt aber eine seine grenzen wenn es um Methoden außer GET geht. Denn um eine Anfrage zu stellen werden Parameter benötigt, diese Information kann HAL nicht abbilden. https://json-schema.org/ schon.. Aber du musst dir das Schema erst mal holen um das eigentliche Json zu verstehen . Bedeutet zwei Anfragen, A: daten B: schema...
Das Problem ist gibt vieles mit vor und Nachteile... Es gibt niemanden der ein UI Programmiert also ist die Entscheidung sehr schwer... Mit dem Schema kann man bis zum UI alles beschreiben, z.Bsp ein im Control Descriptor mit einen Fader kann so beschrieben werden das die UI Applikation einen Fader rendert.
Sinn also ist es die Daten so zu beschreiben das die zukünftige Anwendung sich anhand dieser Daten selber baut
. Das ist wichtig da die Geräte alle unterschiedliche Eigenschaften haben und man diese Eigenschaften schlecht statisch darstellen kann. Gerade was Control angeht. Da macht es Sinn einen UI Generator zu benutzen 
.Genau dieser Pikante Ansatz mit REST API macht den Unterschied zwischen anderen Controllern aus! Außerdem lassen sich Geräte auch außerhalb der AVB Domain und des lokalen Netzes verwalten.
Achso - und ich dachte du generierst die jSons und dein Controller will drüber angesteuert werden, sodass ein client mit oder ohne UI auch von einem andren rechner im netzwerk aus werkeln könnte.
Da hätt ich mal einen Versuch mit einem simplen VB client gestartet, aber das scheint ein grobes Missverständis gewesen zu sein. Java und Html kann ich leider (noch?) nicht
versteh ich das richtig dass die reader- & talker- devices dir diese Jsons abfragen lassen und dem controller seine eigenschaften mitteilen?
kannst mir das kurz erklären? (ist das eine standardisierte URI oder bei jedem Hersteller/gerät andreas?)
Gruß
Dominik
-
Da schon ganz viele, wir reden von 7 Leute den Workspace herunter geladen haben besteht denn Interesse das mal Live auszuprobieren ? Prinzipiell bestünde die Möglichkeit das ich einen VPN Zugang frei schalten zum AVB Testfeld. In dem Workspace sind Umgebungsvariablen, die sind dann auf die Adresse des Controllers zu ändern... Erkläre ich dann wie das geht...
wahrscheinlich "etwas" verspätet - aber ja das Interesse wäre da.
-
Hallo,
ich finde toll was du da machst! Ich hätte nur noch eine Frage: du schreibst immer dass die sache "auf dem Switch läuft". Mir ist nicht klar auf welcher Hardware weiter vorne war vom Netgear GS724 die Rede bzw dass du zugriff aufs Extranet erhalten hattest - jedoch schien mir du hattest den ansatz verworfen.
Dann ist wieder vom XMOS die Rede hast du hier die Module weiterverwendet die du weiter vorne mal fotografiert hattest?
Ich hab schon ein wenig erfahrung mit REST-APIs und jSon, hab aber noch keine AVB HW im das ganze nachzustellen (abgesehen von 2 Rechnern mit intel i210).
Gruß
Dominik