Diskussion:Hausbus2: Unterschied zwischen den Versionen

Aus RaumZeitLabor Wiki
Keine Bearbeitungszusammenfassung
Zeile 11: Zeile 11:


* Halte ich nicht für nötig. In allen modernen Sprachen sind Routen/Endpunkte frei definierbar, eine Notwendigkeit für einen "Unterordner" gibt es nicht. In Anbetracht der Tatsache, dass die Server außer der API nichts anderes anbieten (oder höchstens eine index.html mit Hilfe) ist das auch ziemlich redundant. Der Pfad _ ist so gewählt, dass er "privat" impliziert (für Python/Perl-Programmierer z.B.) und mit keinem anderen, "sprechenden" Endpunkt kollidiert. --[[Benutzer:SEC|sECuRE]] 19:31, 16. Apr. 2012 (CEST)
* Halte ich nicht für nötig. In allen modernen Sprachen sind Routen/Endpunkte frei definierbar, eine Notwendigkeit für einen "Unterordner" gibt es nicht. In Anbetracht der Tatsache, dass die Server außer der API nichts anderes anbieten (oder höchstens eine index.html mit Hilfe) ist das auch ziemlich redundant. Der Pfad _ ist so gewählt, dass er "privat" impliziert (für Python/Perl-Programmierer z.B.) und mit keinem anderen, "sprechenden" Endpunkt kollidiert. --[[Benutzer:SEC|sECuRE]] 19:31, 16. Apr. 2012 (CEST)
== Proposed Updates 18. Dezember 2012 ==
Ich hab im Python-Module eine relativ wichtige Änderung gemacht: Die Werte werden vom Status-Endpunkt nun nicht mehr als flacher JSON ausgegeben, sondern verschachtelt. Das macht IMHO wesentlich mehr Sinn als die aktuelle Spezifikation, die die Unterteilung im jeweiligen Key durch den Punkt vornimmt.
Heißt im Beispiel von vorne nun also nicht mehr:
{"pinpad.door": "locked",
  "pinpad.lastsync": 1321819942,
  "pinpad.wrongpins": 3,
  "pinpad.msg": "Willkommen im RZL"}
Sondern:
{ "pinpad": {
    "door": "locked",
    "lastsync": 1321819942,
    "wrongpins": 3,
    "msg": "Willkommen im RZL"
  }
}
Das vereinfacht das Parsen des JSONs ungemein. Gibt es da Einwände gegen?
Ansonsten wäre ich dafür, MQTT zur Propagierung von Events zu nutzen. Eine Message Queue ist an der Stelle durchaus sinnvoll, um die Busendgeräte nicht unnötig durch Polling zu belasten. Warum MQTT?
* Simpel
* Brauch extrem wenig Bandbreite
* Implementierung in vielen Sprachen verfügbar
* Kann Nachrichten persistieren
* Kann Authentifizierung und Berechtigungen und so
* Erlaubt einen "last will", eine Meldung, wenn ein Client abschmiert
Nachteil: Wir brauchen einen zentralen Broker. Aber das kann man IMHO verschmerzen.
--[[Benutzer:Tiefpunkt|Tiefpunkt]] ([[Benutzer Diskussion:Tiefpunkt|Diskussion]]) 00:06, 18. Dez. 2012 (CET)

Version vom 17. Dezember 2012, 23:06 Uhr

Sprechendere Pfade

Mein Vorschlag wäre, die Pfade ein wenig sprechender zu machen, und die API in einen Unterordner zu schieben. So kann man auch eine Art Web-Interface auf den Hausbus2-Nodes implementieren, ohne der API in die Quere zu kommen. Konkret würde das heißen, um mal die Beispiele zu nutzen:

  • /api/common/state
  • /api/common/state/pinpad.door
  • /api/common/reboot
  • /api/unlock_door
  • /api/look_door

Wie seht ihr das? --Tiefpunkt 09:22, 23. Jan. 2012 (CET)

  • Halte ich nicht für nötig. In allen modernen Sprachen sind Routen/Endpunkte frei definierbar, eine Notwendigkeit für einen "Unterordner" gibt es nicht. In Anbetracht der Tatsache, dass die Server außer der API nichts anderes anbieten (oder höchstens eine index.html mit Hilfe) ist das auch ziemlich redundant. Der Pfad _ ist so gewählt, dass er "privat" impliziert (für Python/Perl-Programmierer z.B.) und mit keinem anderen, "sprechenden" Endpunkt kollidiert. --sECuRE 19:31, 16. Apr. 2012 (CEST)

Proposed Updates 18. Dezember 2012

Ich hab im Python-Module eine relativ wichtige Änderung gemacht: Die Werte werden vom Status-Endpunkt nun nicht mehr als flacher JSON ausgegeben, sondern verschachtelt. Das macht IMHO wesentlich mehr Sinn als die aktuelle Spezifikation, die die Unterteilung im jeweiligen Key durch den Punkt vornimmt. Heißt im Beispiel von vorne nun also nicht mehr: 

{"pinpad.door": "locked",
 "pinpad.lastsync": 1321819942,
 "pinpad.wrongpins": 3,
 "pinpad.msg": "Willkommen im RZL"}

Sondern: 

{ "pinpad": {
   "door": "locked",
   "lastsync": 1321819942,
   "wrongpins": 3,
   "msg": "Willkommen im RZL"
  }
}

Das vereinfacht das Parsen des JSONs ungemein. Gibt es da Einwände gegen?

Ansonsten wäre ich dafür, MQTT zur Propagierung von Events zu nutzen. Eine Message Queue ist an der Stelle durchaus sinnvoll, um die Busendgeräte nicht unnötig durch Polling zu belasten. Warum MQTT?

  • Simpel
  • Brauch extrem wenig Bandbreite
  • Implementierung in vielen Sprachen verfügbar
  • Kann Nachrichten persistieren
  • Kann Authentifizierung und Berechtigungen und so
  • Erlaubt einen "last will", eine Meldung, wenn ein Client abschmiert

Nachteil: Wir brauchen einen zentralen Broker. Aber das kann man IMHO verschmerzen.

--Tiefpunkt (Diskussion) 00:06, 18. Dez. 2012 (CET)

Abgerufen von „https://wiki.raumzeitlabor.de/index.php?title=Diskussion:Hausbus2&oldid=8745“