[Umfrage] Welche Programmiersprache sollen wir als nächstes unterstützen?

[Equinox]

Hallo,

 

Genau, geschickter als JavaScript direkt zu nutzen.

 

Ahh, ich glaube jetzt habe ich verstanden, was du mit deinem ursprünglichen Post gemeint hast. Es ging dabei um nicht um den Vorschlag, WebServices "standalone" auf dem Master Brick anzubieten, sondern um "echte" JavaScript-Bindings für den Browser? Falls ja, dann bin ich wieder in der Spur 

 

Ich handel mir doch sonst nur Probleme ein. Wenn ich mit meinem Handy von extern die Webseite aufrufe und der Code im Browser läuft dann muss ich die IP von mir zuhause kennen, der Port muss freigeschaltet sein, da gibt es offensichtliche Sicherheitsprobleme etc.

 

Hmm, da sehe ich jetzt keinen Unterschied zu einem in meinem LAN betriebenen Web-Server. Auch hier muss ich im  Router den Port freischalten und die IP-Adresse kennen (wobei man hier ja im Normalfall sowas wie DynDNS nutzt).

 

Es macht doch nur Sinn den Code im Client (also im Browser) auszuführen wenn der Server selbst keinen Zugriff auf die Bricks hat.

 

In dem Fall und im Fall, dass man gar keinen Server hat. Ich denke, dass es nicht so selten ist, dass ein Web-Server im eigenen LAN keinen Zugriff auf die Bricks hat.

 

Aber mal eine Frage: Wenn ihr Bindings für Node.js entwickelt, funktionieren die dann nicht "automatisch" für JavaScript im Browser? D.h., wären das dann nicht zwei Fliegen mit einer Klappe?

[borg]

Aber mal eine Frage: Wenn ihr Bindings für Node.js entwickelt, funktionieren die dann nicht "automatisch" für JavaScript im Browser? D.h., wären das dann nicht zwei Fliegen mit einer Klappe?

 

Node.js ist ein Webserver den man mit JavaScript programmieren kann. Node.js läuft nicht im Browser, ein Großteil von Node.js ist in C++ geschrieben...

[Equinox]

Node.js ist ein Webserver den man mit JavaScript programmieren kann.

 

Eben. Eine Plattform (mit dem auch auch einen Web-Server implementieren kann), die man mit JavaScript programmieren kann. Wenn eure Bindings also auch in JavaScript geschrieben werden, dann sollte das doch auch im Browser laufen (es sei denn, es werden "verbotene" Operationen (Dateizugriffe usw.) verwendet)?!

[borg]

Eben. Eine Plattform (mit dem auch auch einen Web-Server implementieren kann), die man mit JavaScript programmieren kann. Wenn eure Bindings also auch in JavaScript geschrieben werden, dann sollte das doch auch im Browser laufen (es sei denn, es werden "verbotene" Operationen (Dateizugriffe usw.) verwendet)?!

 

Das Programmiermodell in node.js ist absolut asynchron. Dadurch sieht das JavaScript dort ganz anders aus als man es für den Browser schreiben würde.

 

Hinzu kommt das die Bindings für node.js auf dem net package basieren (http://nodejs.org/api/net.html) müssen, welches im Browser nicht existiert.

 

Da wird man also zumindest nicht den kompletten Code wiederverwenden können, evtl aber einen Teil. Dazu müsste ich mir das aber erst genauer angucken und einen Mockup schreiben.

[AuronX]

1. Vermutlich gehört die RPC-Diskussion in einen extra Thread weil es keine neue Sprache wäre...

2. Ich sehe nicht wo das den Standalone-Betrieb erleichtert

 

Kein Rechner: Keiner stellt anfragen an den Webservice

Smartphone: Objective-C / Java und alle sind glücklich mit den existierenden Bindings

[Nemo]

Hallo zusammen,

 

irgendwie dringe ich noch nicht so durch die Diskussion durch, ich habe zwar alles aufmerksam gelesen aber irgendwie erschließt sich mir der Vorteil von node.js gegenüber PHP oder anderen Sprachen nicht.

Ich meine irgendein Rechner muss immer laufen wenn man Daten auslesen will.

Macht man das mit PHP packt man einfach den XAMMP, MAMP oder LAMP in den Autostart und bei node.js muss man auch einen Server starten.

Sehe ich den Wald vor lauter Bäumen nicht oder stehe ich irgendwie auf dem Schlauch?

 

Gruß,

Nemo

[borg]

Du hast das schon richtig verstanden. Node.js/JavaScript wäre ein weiteres Binding, genauso wie PHP.

[Equinox]

Sehe ich den Wald vor lauter Bäumen nicht oder stehe ich irgendwie auf dem Schlauch?

 

Es sind drei(?) Diskussionen:

[*]Node.js: Das wäre einfach nur ein weiteres Binding wie PHP, Java, usw.

[*]"WebService auf MasterBrick": Hier geht es darum, sprachunabhängig die Daten der Bricklets ohne Server und ohne Installation von irgendwelchen Bindings auf dem Client auszulesen. Da dies aber wohl nicht geht, ist die Diskussion hinfällig (es sei denn, es kommt einer und sagt dies dies realistisch möglich ist).

[*]JavaScript im Browser: Binding wie PHP, Java, usw., aber eben ausgeführt im Browser.

 

(So habe ich es zumindest verstanden )

[Unexpected]

Ich habe das auch so verstanden, wie Equinox noch mal zusammen gefasst hat.

Da hätte ich noch mal eine Frage allerdings zu. Was ist der unterschied zwischen JavaScript und Node.js?

JavaScript direkt als Binding würde ich beführworten ( wenn dies so "einfach" umzusetzten ist), auch wenn es wohl keine großen Vor- oder Nachteile zu PHP hätte oder? Außer dass es im Browser direkt ausgeführt wird.

[AuronX]

Node.js ist im wesentlichen ein eigener Server der mittels Javascript programmiert wird. Das heißt du nutzt Javascript als Programmiersprache, hast aber mehr API für Dinge, die im Browser nicht gehen/gewollt sind: Dateizugriff, echte Sockets usw.

 

Der Unterschied ist also, dass es eigentlich zwei Dinge sind:

1. JavaScript eine Sprache

2. node.js: Ein Server der JS ausführt und dazu API in JS bereitstellt die es im Browser nicht gibt

 

JavaScript direkt als Binding würde ich beführworten ( wenn dies so "einfach" umzusetzten ist), auch wenn es wohl keine großen Vor- oder Nachteile zu PHP hätte oder?

 

Vor- und Nachteile sind wohl Geschmacksfrage

 

Außer dass es im Browser direkt ausgeführt wird.

 

Das würde nicht für node.js gelten.

JavaScript-Bindings im Browser halte ich derzeit für nicht umsetzbar, aber ich bin tatsächlich nicht all-zu bewandert auf diesem Gebiet

[borg]

Equinox hat das gut zusammengefasst.

 

 

Ich hab mal ein bisschen rumgebastelt und folgendes gebaut:

 

• Einen kleinen Websocket-Server mit libwebsocket (http://libwebsockets.org/trac/libwebsockets) der ein Enumerate auf einem Brick aufrufen kann
  
• Eine kleine Webseite die Code beinhaltet die mit Websockets (per JavaScript) auf auf den Server zugreift und das Enumerate aufruft und die Rückgabe ausgibt.
  

 

Das funktioniert einwandfrei.

 

Mein Gedanke ist folgender: Brickd könnte auf einem weiteren Port einen Websocket öffnen auf dem über Websockets unser ganz normales Protokoll gesprochen wird. Dazu könnte man dann "echte" JavaScript Bindings machen.

 

Dann könnten wir einen Online Brick Viewer anbieten den ihr aufrufen könntet der dann eine Webseite bei uns vom Server holt die sich lokal mit dem Brickd verbindet. Dabei liefern wir nur das HTML/JavaScript, wir kriegen nichts von den Daten mit, die bleiben komplett auf eurem Rechner.

 

Damit hätten wir dann einen brickv den man nicht installieren muss der auf Handys/Tablets etc läuft.

 

 

Was meint ihr, macht das Sinn?

[AuronX]

Auf jeden Fall!

 

Ich bin wieder nicht auf den guten Gedanken gekommen den brickd zu erweitern.

 

Wäre das auch auf den TCP-Extensions (WLAN/LAN) implementierbar? Weil ansonsten natürlich wieder ein Ungleichgewicht entsteht das unter Umständen schwer erklärbar ist... (JS geht nur mit "vanilla" brickd, aber nicht mit Extensions)

 

Ansonsten eine sehr coole Idee. Es wäre ja trotzdem möglich den "Online-Brickv" auch herunterzuladen und auf einem eigenen Server zu platzieren.

[borg]

Wäre das auch auf den TCP-Extensions (WLAN/LAN) implementierbar? Weil ansonsten natürlich wieder ein Ungleichgewicht entsteht das unter Umständen schwer erklärbar ist... (JS geht nur mit "vanilla" brickd, aber nicht mit Extensions)

Das gucke ich mir gerade an. Dafür müssten wir einen kleinen Webserver sowie das Websocket Handshaking implementieren. Das Handshaking nutzt HTTP als Protokoll (deswegen einen Webserver) und es muss leider über Hashes ein Globally Unique Identifier berechnet werden (Sec-WebSocket-Key). Dabei teilt der Client dem Server dann mit welches Protokoll er sprich (in unserem Fall tfp) und dann danach könnte dann ganz normal TCP/IP gesprochen werden.

 

So ist aktuell mein Verständnis .

Ansonsten eine sehr coole Idee. Es wäre ja trotzdem möglich den "Online-Brickv" auch herunterzuladen und auf einem eigenen Server zu platzieren.

Klar.

[Unexpected]

Vielen Dank euch beiden für die Erklärungen!

Das sind coole Ideen, wie ich finde!

 

Ein runterladen des "Online-Brickv" wäre mir auch wichtig. Einfach aus dem Grund, dass man dann evtl. auch die Möglichkeit hat die Version weiter lokal anzupassen.

 

Ansonsten super Idee! :-)

[Equinox]

Coole Sache 

 

Aber wenn das geht:

Wäre das auch auf den TCP-Extensions (WLAN/LAN) implementierbar?

 

Dann müsste doch auch das gehen:

2. "WebService auf MasterBrick": Hier geht es darum, sprachunabhängig die Daten der Bricklets ohne Server und ohne Installation von irgendwelchen Bindings auf dem Client auszulesen. Da dies aber wohl nicht geht, ist die Diskussion hinfällig (es sei denn, es kommt einer und sagt dies dies realistisch möglich ist).

 

Wobei der WebService dann eben nicht auf dem Master Brick läuft, sondern auf der WiFi- bzw. Ethernet-Extension.

Wenn ein "Full-Blown" WebService zu aufwändig ist, dann könnte ich mir auch einen ganz normalen HTTP GET-Request vorstellen. So in der Art:

 

http://<IP des Stapels>:<Port>/<Bricklet UID>/<getter>

oder

http://<IP des Stapels>:<Port>/<getter(Bricklet UID)>

 

Also z.B.:

http://192.168.10.100:80/aBC/getHumidity()

Der Aufruf gibt dann einfach die gemessene Luftfeuchtigkeit zurück, also z.B. 758 (für 75,8%).

[kreaktiv]

Ich habe das Gefühl die Diskussion geht weit auseinander.

TF fragt nach einer weiteren Programmiersprache.

Ein Teil der Antworten handeln von einem implementierten Kleinserver.

Oder wie Equinox zusammen gefasst hat; Punkt 2 "WebService auf MasterBrick".

 

Zumindest trifft das meine Bedürfnisse. TF eigenständig machen, so dass es auch ohne fremd Computer (Raspberry etc.) einfache Aufgaben ausführen kann. Ob diese "Intelligenz" ins Master-Brick gehört, oder ev. im Ethet-Brick besser passt, lass ich offen.

 

Unter "einfachen Aufgaben" stelle ich mir vor, kleine Scripte (24/7) laufen zu lassen, deren Daten zu speichern und ggf. zu exportieren. Eine einfach http-Kommunikation (TCP/IP) bis hin zu einem kleinen WebServer. Und dieser soll auf Befehle reagieren können und Antworten geben.

Beispielsweise die bisherige "Wetterstation" komplett, ohne Fremdcomputer, zu betreiben und ein CSV-File führen.

Weshalb kein Raspberry? Zu Leistungsfähig, zu gross, zuviel Stromverbrauch (84Wh/Tag) für Insellösung.

 

Wie gross der Aufwand, und das daraus folgende Preis/Leistungsverhältnis, sein wird kann ich nicht abschätzen.

[Nic]

Jo, die Diskussion geht hier recht einseitig in Richtung Javascript clientseitig im Browser oder wenn ichs richtig verstehe mittels eines Webservers oder Webservice als Standalone Service/Server.

Mal so nebenbei, werden Callbacks via Webservice oder Webserver unterstützt

[Equinox]

Hallo,

 

Mal so nebenbei, werden Callbacks via Webservice oder Webserver unterstützt

 

Die angedachte Implementierung des Brickd soll WebSockets nutzen. Damit sind Callbacks möglich, d.h. der Server kann "unaufgefordert" Daten an den Client schicken. Da bei "normalen" WebServices keine Verbindung bestehen bleibt, geht es da nicht.

[Nic]

Wo "leben" diese Websockets ? Im Browser oder Server ? Bräuchte ich nur die clientseitige App ?

 

Achso wenn ich die anderen Posts richtig lese, ist das im Browser via Javascript eine Websocket-Verbindung zum BrickD, der dazu angepasst werden müsste.

[Equinox]

Achso wenn ich die anderen Posts richtig lese, ist das im Browser via Javascript eine Websocket-Verbindung zum BrickD, der dazu angepasst werden müsste.

 

Genau. Der Browser baut eine Verbindung via WebSocket zum BrickD auf. Diese Verbindung bleibt bestehen, wobei der Server (BrickD) "unaufgefordert", d.h. ohne erneuten Request vom Client, Daten an den Browser schicken kann.

[The_Real_Black]

Ein BrickD Webserver welcher einen gezielt die Werte zurück gibt wäre genial, denn im Moment bastle ich selber sowas in C# bzw. Java. Eine allgemeine Lösung welche direkt im BrickD implementiert ist, kann einiges vereinfachen.

[raphael_vogel]

borg:

Dann könnten wir einen Online Brick Viewer anbieten den ihr aufrufen könntet der dann eine Webseite bei uns vom Server holt die sich lokal mit dem Brickd verbindet. Dabei liefern wir nur das HTML/JavaScript, wir kriegen nichts von den Daten mit, die bleiben komplett auf eurem Rechner.

 

Wäre das dann nicht Cross-Domain communication im Browser? Dann solltet ihr nicht vergessen CORS einzusetzen. (Cross-origin resource sharing)

[raphael_vogel]

Ein BrickD Webserver welcher einen gezielt die Werte zurück gibt wäre genial, denn im Moment bastle ich selber sowas in C# bzw. Java. Eine allgemeine Lösung welche direkt im BrickD implementiert ist, kann einiges vereinfachen.

 

So wie ich das verstehe würde der Web Server im brickd dann aber nur für den initialen Verbindungsaufbau HTTP sprechen, um dann eine WebSocket Verbindung aufzumachen. Sonst könnte er keine HTTP Verarbeitung.

Die Abfrage von Bricklets wäre dann erstmal nur über die WebSockets Verbindung möglich.

HTTP Abfragen wie z.B. http://server:port/<brickletID>/getTemperature

wären dann nicht möglich.

[photron]

Ein BrickD Webserver welcher einen gezielt die Werte zurück gibt wäre genial, denn im Moment bastle ich selber sowas in C# bzw. Java. Eine allgemeine Lösung welche direkt im BrickD implementiert ist, kann einiges vereinfachen.

 

So wie ich das verstehe würde der Web Server im brickd dann aber nur für den initialen Verbindungsaufbau HTTP sprechen, um dann eine WebSocket Verbindung aufzumachen. Sonst könnte er keine HTTP Verarbeitung.

Die Abfrage von Bricklets wäre dann erstmal nur über die WebSockets Verbindung möglich.

HTTP Abfragen wie z.B. http://server:port/<brickletID>/getTemperature

wären dann nicht möglich.

 

Richtig, brickd kann einen WebSocket öffnen, weil er dazu nicht wissen muss welche Bricks und Bricklets es gibt und welche Funktionen sie haben. Denn nach dem HTTP Websocket Handshake würde einfach das normale TCP/IP Protokoll über den WebSocket gesprochen, das brickd jetzt auch schon behandelt.

 

Für RESTartige Dinge die wie http://server:port/<brickletID>/getTemperature müsste brickd aufmal wissen, wie das Paket für getTemperature aussieht. Er muss also die Informationen kennen, die in den Bindings stecken. Das wollen wir vermeiden, brickd soll hier generisch bleiben. Eine RESTartige Schnittstelle würde also eher als extra Proxy realisiert werden, der brickd vorgeschaltet wird. So ein Proxy stellt z.B. der listen Befehl der Shell Bindings dar, der über einen Socket Textbefehle entgegennimmt und dann weiss wie die getTemperature aussieht.

[Equinox]

Hallo,

 

Eine RESTartige Schnittstelle würde also eher als extra Proxy realisiert werden, der brickd vorgeschaltet wird. So ein Proxy stellt z.B. der listen Befehl der Shell Bindings dar, der über einen Socket Textbefehle entgegennimmt und dann weiss wie die getTemperature aussieht.

 

Ich glaube, die Frage, ob das im BrickD oder in einem vorgeschalteten Proxy passiert, ist für den Endbenutzer/Entwickler letztlich egal. Wichtig ist, *wo* das läuft, d.h. würde der vorgeschaltete Proxy dann auch auf dem Stapel laufen oder auf einem zusätzlichen Rechner. Wenn das auch auf dem Stapel ginge, dann wäre es wirklich genial.