Diskussion:Hausbus2 - Versionsgeschichte

Tiefpunkt: /* Proposed Updates 18. Dezember 2012 */

2012-12-18T11:53:58Z

Proposed Updates 18. Dezember 2012

← Nächstältere Version		Version vom 18. Dezember 2012, 11:53 Uhr
Zeile 41:		Zeile 41:

	--[[Benutzer:Tiefpunkt\|Tiefpunkt]] ([[Benutzer Diskussion:Tiefpunkt\|Diskussion]]) 00:06, 18. Dez. 2012 (CET)		--[[Benutzer:Tiefpunkt\|Tiefpunkt]] ([[Benutzer Diskussion:Tiefpunkt\|Diskussion]]) 00:06, 18. Dez. 2012 (CET)

	* Inwiefern soll sich da jetzt das parsen vereinfacht haben? IMHO ist die Trennung mit Punkt die einfachere Variante zum Parsen ;-) Bzgl. MQTT: Klingt interessant. Könntest du, wenn du mal wieder da bist, einen Vortrag drüber halten?		* Inwiefern soll sich da jetzt das parsen vereinfacht haben? IMHO ist die Trennung mit Punkt die einfachere Variante zum Parsen ;-) Bzgl. MQTT: Klingt interessant. Könntest du, wenn du mal wieder da bist, einen Vortrag drüber halten?

			** Nun, der Status hat ja hierarchische Struktur. Beim Pinpad vllt weniger(nur "pinpad." im Beispiel), aber zum Beispiel bei der Heizungssteuerung gibt es aktuell 3 Kategorien, "temperature.", "windows." und "io_ports." (und es werden wohl noch mehr werden). JSON kann diese Hierarchie nativ darstellen, und das macht es IMHO einfacher, wenn ich mich auf eine Kategorie beschränken will mit meiner Applikation, da ich die Kategorie einfach so als Variable übernehmen kann, und nicht erst jeden Key parsen muss. Wegen MQTT mach ich gerne mal nen Vortrag, aber vorher möchte ich noch n bisschen damit rumspielen. Gibt auch einen ganz gutes Youtube-Video[https://www.youtube.com/watch?v=-KNPXPmx88E] dazu, ist allerdings ne gute Stunde lang. Aber Vortrag steht auf der ToDO-Liste :) --[[Benutzer:Tiefpunkt\|Tiefpunkt]] ([[Benutzer Diskussion:Tiefpunkt\|Diskussion]]) 12:53, 18. Dez. 2012 (CET)

Else: /* Proposed Updates 18. Dezember 2012 */

2012-12-18T10:59:10Z

Proposed Updates 18. Dezember 2012

← Nächstältere Version		Version vom 18. Dezember 2012, 10:59 Uhr
Zeile 41:		Zeile 41:

	--[[Benutzer:Tiefpunkt\|Tiefpunkt]] ([[Benutzer Diskussion:Tiefpunkt\|Diskussion]]) 00:06, 18. Dez. 2012 (CET)		--[[Benutzer:Tiefpunkt\|Tiefpunkt]] ([[Benutzer Diskussion:Tiefpunkt\|Diskussion]]) 00:06, 18. Dez. 2012 (CET)
			* Inwiefern soll sich da jetzt das parsen vereinfacht haben? IMHO ist die Trennung mit Punkt die einfachere Variante zum Parsen ;-) Bzgl. MQTT: Klingt interessant. Könntest du, wenn du mal wieder da bist, einen Vortrag drüber halten?

Tiefpunkt: Neuer Abschnitt /* Proposed Updates 18. Dezember 2012 */

2012-12-17T23:06:21Z

Neuer Abschnitt Proposed Updates 18. Dezember 2012

← Nächstältere Version		Version vom 17. Dezember 2012, 23:06 Uhr
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)

SEC am 16. April 2012 um 17:31 Uhr

2012-04-16T17:31:04Z

← Nächstältere Version		Version vom 16. April 2012, 17:31 Uhr
Zeile 9:		Zeile 9:
	* /api/look_door		* /api/look_door
	Wie seht ihr das? --[[Benutzer:Tiefpunkt\|Tiefpunkt]] 09:22, 23. Jan. 2012 (CET)		Wie seht ihr das? --[[Benutzer:Tiefpunkt\|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. --[[Benutzer:SEC\|sECuRE]] 19:31, 16. Apr. 2012 (CEST)

Tiefpunkt: Sprechendere Pfade

2012-01-23T08:22:40Z

Sprechendere Pfade

Neue Seite

== 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? --[[Benutzer:Tiefpunkt|Tiefpunkt]] 09:22, 23. Jan. 2012 (CET)