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

[borg]

Wir werden vermutlich am nächsten Montag die Perl Bindings veröffentlichen. Wir würden gerne direkt eine weitere Sprache hinterherschieben. Für welche Programmiersprache würdet ihr gerne als nächstes Bindings haben?

[Equinox]

Hallo,

 

ich hätte gern Bindings für Node.js.

[Stefan]

Hallo,

 

ich hätte gern Bindings für Node.js.

 

JavaScript hätte auch den Vorteil, dass man das Binding in HTML5-Apps oder im Browser benutzen könnte, wenn es Schnittstellen für TCP gibt. Diese sind, wenn verfügbar z.B. Firefox OS, zwar im Moment sehr proprietär und man müsste das Binding immer daran anpassen, aber vielleicht gibt es irgendwann ein einheitlicher Standard.

[Loetkolben]

Oh, das hoert sich prima an. Geht das ueberhaupt?

 

Damit koennte man Browserapps schreiben ohne einen weiteren Server bemuehen zu muessen. Soll heissen: Die "App"/Webseite wird auf www.meinhosting.de gehostet, schaltet dann aber DIREKT im LAN die 192.168.x.x Steckdosen.

 

Interessant.

 

Der Loetkolben

[Unexpected]

Hallo zusammen,

 

also wenn das möglich wäre, würde ich javaskript auch beführworten :-)

 

Grüße

Unex

[raphael_vogel]

Ich bin auch für JavaScript, aber TF sollte auf jeden Fall mit serverseitigem JavaScript anfangen (node.js). TCP connections mit Javascript vom Browser aus ist noch nicht standardisiert. Die "raw socket API" ist beim W3C noch im draft modus. Da kann es noch einige Änderungen geben....

http://www.w3.org/2012/sysapps/raw-sockets/

 

Es gibt natürlich jetzt schon Browser abhängige Implementierungen (z.B. in  Chrome), aber die sind herstellerspezifisch, und TF will bestimmt nicht alle paar Monate ihre JS Bindings anpassen. http://developer.chrome.com/apps/app_network.html

[Equinox]

Hallo,

 

das WebSocket-Protokoll ist schon seit Ende 2011 im Status "Proposed Standard", aber de facto ist es ein verabschiedeter Standard, da ihn meines Wissens alle modernen Browser unterstützen. Einer Kommunikation zwischen Browser und Server steht also nichts im Wege. Die Frage ist nur, ob bzw. wie man mit Node.js mit der TF Hardware reden kann. Ich denke aber, dass das gehen sollte, notfalls über die Shell :-)

[tatzemax]

Fup Kop Ablaufsteuerung....  SPS

[borg]

WebSockets sind keine "normalen" Sockets, damit können wir nicht unser Protokoll sprechen.

 

Node.js kann normale Sockets, man könnte also Node.js Bindings machen die genauso funktionieren wie unsere anderen Bindings auch.

 

Zum testen hab ich ein schnelles Node.js Programm geschrieben das ein Enumerate macht:

var s = require('net').Socket();
s.connect(4223, 'localhost');
buf = new Buffer(new Array(0, 0, 0, 0, 8, 254, 48, 0));
s.write(buf);
s.on('data', function(d){
    console.log(d);
});

 

Funktioniert problemlos.

[Equinox]

Cool 

Das Ganze jetzt noch schön verpackt wie bei den anderen Bindings und schon ist auch das fertig 

 

Dann hätte ich noch einen Wunsch (wobei ich befürchte, dass dies nicht machbar ist): Ich hätte gern einen WebServer auf dem Masterbrick, der mir die ganzen "Getter" und "Setter" der Bricklets als WebServices zur Verfügung stellt (RPC Style). Diese könnten sprachunabhängig genutzt werden und wären ein erster Schritt zur "standalone" Nutzung der TF Hardware. Die gewünschte "Logik" müsste dann natürlich in den Client-Programmen jeweils selbst implementiert werden. Aber oft will man ja nur einen Wert wissen oder etwas manuell einschalten.

Ist dafür genügend Platz auf dem Masterbrick?

[raphael_vogel]

Ja das wäre Klasse mit dem Web Server auf dem Master.

Wenn das gehen sollte dann aber bitte kein geschwätziges RPC/XML sondern JSON 

[Equinox]

bitte kein geschwätziges RPC/XML sondern JSON

 

Naja, die paar Bytes machen den Kohl nicht fett. Mir ist wichtig, dass ich eine WSDL zur Verfügung habe und damit der Zugriff (bei den meisten Programmiersprachen) sehr einfach wird.

Wenn es um die Datenmenge geht, dann ist auch JSON schon zuviel, also einfach nur den Wert ohne Schnickschnack drumherum zurückgeben.

Aber man kann ja auch beides unterstützen. Meines Wissens kann der Client in seinem Request angeben, in welchem Format er die Antwort gerne haben möchte.

Die Frage ist nur, ob es einen genügend schlanken Webserver gibt, der diese Aufgaben auf dem Masterbrick erledigen kann.

[borg]

Der Master selbst ist ja erstmal per USB an einem PC angeschlossen und kann somit auch kein JSON o.ä. anbieten da er kein TCP/IP spricht.

 

Einen kleinen Daemon zu schreiben der eine JSON oder RPC/XML oder was auch immer API anbietet ist natürlich kein Problem, das tun wir ja z.B. schon für netio: http://www.tinkerforge.com/de/doc/Software/NetIO_Setup.html

 

Ich verstehe das aber nicht so ganz. Ihr wollt dann z.B. per Java auf die Schnittstelle zugreifen? Warum dann nicht sofort die Java Bindings nehmen?

 

Also mit welcher Programmiersprache die wir aktuell noch nicht unterstützen wollt ihr das JSON o.ä. verwerten?

[Daniel]

Hallo zusammen,

 

AutoIt wäre vielleicht auch nicht schlecht...

http://www.autoitscript.com/site/autoit/

 

Viele Grüße

Daniel

[Equinox]

Hallo,

 

Ich verstehe das aber nicht so ganz. Ihr wollt dann z.B. per Java auf die Schnittstelle zugreifen? Warum dann nicht sofort die Java Bindings nehmen?

Also mit welcher Programmiersprache die wir aktuell noch nicht unterstützen wollt ihr das JSON o.ä. verwerten?

 

Weil ja schon lange die Idee kursiert, Programme standalone auf dem Masterbrick laufen zu lassen, wäre das einfach nur ein erster Schritt dorthin bzw. eine "Light"-Möglichkeit, die TF-Hardware ohne zusätzlichen Rechner abzufragen bzw. zu nutzen. Einen zusätzlichen Daemon mit JSON oder RPC/XML-API brauche ich nicht, solange er weiterhin einen eigenen Rechner braucht.

Wenn das also nicht geht, dann wäre mein nächster Wunsch nur die Unterstützung von Node.js.

[borg]

Ich verstehe die Logik nicht .

 

Angenommen ein Master Brick könnte eine JSON API anbieten, wie würde dann etwas Standalone auf dem Brick laufen?

 

Oder meinst du einfach das man direkt über TCP/IP mit dem Brick kommunizieren kann? Dafür haben wir doch schon die Ethernet Extension!

[Equinox]

Hallo,

 

Angenommen ein Master Brick könnte eine JSON API anbieten, wie würde dann etwas Standalone auf dem Brick laufen?

 

Dann würde das Programm, das mir die Daten per JSON, RPC/XML usw. zur Verfügung stellt, standalone auf dem Master Brick laufen. D.h., das wäre im Prinzip "nur" eine andere Schnittstelle, um an die Daten der Bricklets zu kommen.

 

Oder vielleicht anders formuliert: Eine Möglichkeit, dass ein Client direkt auf die Daten der Bricklets zugreifen kann (ohne Rechner/Server dazwischen), wobei die Daten standardisiert über WebServices geliefert werden (RPC/XML, JSON), d.h., dass auch auf dem Client keine TF-spezifischen Bibliotheken/Bindings vorhanden sein müssen. Ein Zugriff auf die Daten wäre damit vollkommen sprachunabhängig, d.h. jede Sprache, die WebServices unterstützt, könnte auf die Daten zugreifen (auch die Sprachen, für die es noch keine TF-Bindings gibt).

[borg]

Oder vielleicht anders formuliert: Eine Möglichkeit, dass ein Client direkt auf die Daten der Bricklets zugreifen kann (ohne Rechner/Server dazwischen), wobei die Daten standardisiert über WebServices geliefert werden (RPC/XML, JSON), d.h., dass auch auf dem Client keine TF-spezifischen Bibliotheken/Bindings vorhanden sein müssen. Ein Zugriff auf die Daten wäre damit vollkommen sprachunabhängig, d.h. jede Sprache, die WebServices unterstützt, könnte auf die Daten zugreifen (auch die Sprachen, für die es noch keine TF-Bindings gibt).

 

OK . Welche Sprache würdest du denn denn verwenden wollen um das JSON o.ä. auszulesen und in welcher Umgebung?

[Equinox]

Welche Sprache würdest du denn denn verwenden wollen um das JSON o.ä. auszulesen und in welcher Umgebung?

 

Das sollte ja dann eigentlich keine Rolle spielen 

Ich würde allerdings Java, PHP, Node.js und (Micro-)Python verwenden. Umgebungen: Windows PC, NAS mit Linux, Raspberry Pi, Android Handy, Microcontroller.

Für das Meiste davon gibt es ja schon Bindings (die auf jeden Fall mächtiger sind als WebServices), aber manchmal kann/möchte man einfach keine zusätzlichen Installationen (d.h. die Bindings) machen.

Ich denke aber, dass es vor allem für euch einfacher wird, da ihr damit automatisch "alle" Programmiersprachen abdecken würdet.

Das hat allerdings keine große Priorität für mich (wichtiger wären die Bindings für Node.js). Und da es eh nicht geht, hat es sich ja eigentlich auch schon erledigt.

[Temp]

Interessant wäre es, wenn der WebService dann REST kann und JSON zurückgibt. Dann kann man den mit JavaScript aufrufen um die Daten direkt in HTML5 / JavaScript Apps zu benutzten.

[borg]

Mh. Vielleicht kenne ich mich bei den Webtechnologien einfach nicht gut genug aus um das zu verstehen .

 

Ist es nicht viel geschickter die Verbindung zum Brick/Bricklet auf der Server Seite mit Python/Ruby/PHP aufzubauen und die eigentlichen Daten über REST/Websockets mit HTML5/JavaScript auf der Client Seite abzufragen?

 

Wenn jeder Aufrufer einer Webseite selbst eine Verbindung zum Brick herstellt ist doch die USB Bandbreite super schnell aufgebraucht.

 

 

Was ich sehen kann ist folgendes:

 

Angenommen man würde Bindings für JavaScript mit den Chrome Sockets machen (http://developer.chrome.com/apps/socket.html), dann könnte man einen Online Brick Viewer entwerfen und man müsste keine Anwendung mehr installieren sondern könnte einfach eine Webseite (mit Chrome) bei uns aufrufen um sich seine lokalen Bricks/Bricklets anzusehen.

 

Das hat aber natürlich den Nachteil das der Brick Viewer nur noch funktioniert wenn man auch Zugriff zum Internet hat, das ist auch komisch .

[Equinox]

Hallo,

 

jetzt bin ich völlig verloren 

Ist es nicht viel geschickter die Verbindung zum Brick/Bricklet auf der Server Seite mit Python/Ruby/PHP aufzubauen und die eigentlichen Daten über REST/Websockets mit HTML5/JavaScript auf der Client Seite abzufragen?

 

Geschickter als was? So muss man es doch im Moment machen, da man sich nicht direkt via JavaScript verbinden kann, oder?

 

Wenn jeder Aufrufer einer Webseite selbst eine Verbindung zum Brick herstellt ist doch die USB Bandbreite super schnell aufgebraucht.

 

?? Wenn eine Abfrage direkt per WebServices möglich wäre, dann wäre der Stapel nicht per USB verbunden, sondern per WiFi- oder Ethernet-Extension (eben standalone). Wenn man das natürlich auf einer hochfrequentierten Seite macht, kann das natürlich trotzdem zu Problemen führen. Aber das wird wohl eher die ganz große Ausnahme sein (typischerweise wird es wohl nur einige wenige Benutzer aus dem eigenen LAN geben). Oder was habe ich hier falsch verstanden?

 

... einfach eine Webseite (mit Chrome) bei uns aufrufen um sich seine lokalen Bricks/Bricklets anzusehen.

 

?? Wieso Webseite bei *euch* aufrufen, um *eigene* Bricklets anzusehen ??

Man könnte damit vmtl. tatsächlich einen Brickviewer über einen Browser basteln, der dann aber im eigenen LAN läuft (also ohne Internet-Zugriff). Oder was geht hier an mir vorbei? Vielleicht ist es einfach zu spät ... 

[Loetkolben]

Das hat aber natürlich den Nachteil das der Brick Viewer nur noch funktioniert wenn man auch Zugriff zum Internet hat, das ist auch komisch .

 

Der ein oder andere hat einen Webspace, aber keinen vServer im Internet oder zu Hause. Damit koennte man Programme erstellen die man dann vom Handy/PC aufrufen kann um sie dann im (lokalen) Haus zu nutzen.

Man beachte: Permanentes Internet ist doch so selbstverstaendlich wie permanenter Strom/Gas/Wasser oder verstehe ich das falsch? 

 

Oder liege nun ich falsch?

 

Der Loetkolben

[Nic]

Für welche Programmiersprache würdet ihr gerne als nächstes Bindings haben?

Da würde ich spontan für dieses Basic entscheiden:  Der TFT-Maximite hat einen Basic-Interpreter.

http://geoffg.net/tft-maximite.html

 

[borg]

Geschickter als was? So muss man es doch im Moment machen, da man sich nicht direkt via JavaScript verbinden kann, oder?

Genau, geschickter als JavaScript direkt zu nutzen.

 

Aber das wird wohl eher die ganz große Ausnahme sein (typischerweise wird es wohl nur einige wenige Benutzer aus dem eigenen LAN geben). Oder was habe ich hier falsch verstanden?

Also die Anwendung ist doch einen eigenen Webserver im eigenen LAN zu besitzen der Webseiten anzeigt?

 

Man könnte damit vmtl. tatsächlich einen Brickviewer über einen Browser basteln, der dann aber im eigenen LAN läuft (also ohne Internet-Zugriff). Oder was geht hier an mir vorbei? Vielleicht ist es einfach zu spät ... 

Ja aber gerade dieser Use Case ist doch schon perfekt abgedeckt? Wenn ich doch einen Webserver im eigenen LAN hab dann schließe ich da doch einfach die Bricks via USB oder Ethernet an, lese die Daten mit einer Programmiersprache meiner Wahl aus und zeige sie auf der Webseite an.

 

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

 

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.

 

Wenn die Bricks/Bricklets aber vom Server abgefragt werden und die Daten einfach auf der Webseite angezeigt werden kann ich von überall drauf zugreifen ohne auch nur irgendwelche Probleme zu erwarten.

 

Oder nicht?