photron Geschrieben January 14, 2014 at 10:21 Geschrieben January 14, 2014 at 10:21 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. Das Problem, dass brickd dann aufmal alle Funktionen mit Namen usw. kennen müsste gilt auch für den Stapel. Dann müssten dort auf einmal auch alle Funktionen mit Namen usw. bekannt sein. Diese Information ist dort nicht vorhanden. Diese Informationen stecken nur in den Bindings. So ein Proxy würde also wahrscheinlich nicht auf dem Master Brick selbst laufen, sondern wie die Shell Bindings im Listen-Modus auf einem extra Rechner. Zitieren
Equinox Geschrieben January 14, 2014 at 11:02 Geschrieben January 14, 2014 at 11:02 Das Problem, dass brickd dann aufmal alle Funktionen mit Namen usw. kennen müsste gilt auch für den Stapel. Dann müssten dort auf einmal auch alle Funktionen mit Namen usw. bekannt sein. Würde das denn grundätzlich gehen? D.h. wäre auf dem Stapel (egal ob auf Master, Extension oder gar Bricklet) soviel Platz, dass man den BrickD oder einen Proxy darauf implementieren kann, der die Funktionen mit Namen kennt? Falls nein, wäre es möglich, eine allgemeine Funktion dafür anzubieten, sozusagen ein "getValue()", das dann eben je nach Bricklet den entsprechenden Wert zurückgibt? Bei mehreren möglichen Werten, sowas wie "getValue(1)" und "getValue(2)" usw.? Zitieren
AuronX Geschrieben January 14, 2014 at 17:07 Geschrieben January 14, 2014 at 17:07 Equinox, wenn du über deine Frage noch einen Moment nachdenkst wirst du merken, dass das nicht funktionieren kann. Woher soll man wissen wie viele getValues es gibt? Woher soll man den rohen Datentyp wissen? (char, (u)int16, (u)int32) Woher soll man wissen wie aus dem rohen Wert der "richtige Wert wird? Was ist mit settern? Und viel wichtiger: Was würde das ganze am Ende denn nützen? Dann habe ich irgendeinen Dienst den ich wieder nach irgendetwas fragen kann. Aber mit was frage ich das ganze dann ab? Der Client muss ja doch wieder irgendein Protokoll sprechen. Mir erschließt sich nicht an welcher Stelle ein Web-Service mächtiger/portabler wäre... Zitieren
Equinox Geschrieben January 14, 2014 at 21:08 Geschrieben January 14, 2014 at 21:08 Woher soll man wissen wie viele getValues es gibt? Was meinst du mit "man"? Den Entwickler? Falls ja, dann ist es einfach: Der Entwickler weiß, um welches Bricklet es sich handelt und damit weiß er, wieviele Getter es gibt. Abgesehen davon kann evtl. ja der Server feststellen, um was für ein Bricklet es sich handelt (wie beim enumerate). Woher soll man den rohen Datentyp wissen? (char, (u)int16, (u)int32) Auch das ist einfach: Immer einen String zurückgeben. Woher soll man wissen wie aus dem rohen Wert der "richtige Wert wird? Woher weißt du das jetzt? Ist nichts anderes ... Was ist mit settern? Die braucht man natürlich auch, habe ich nur der Einfachheit halber weggelassen. Aber mit was frage ich das ganze dann ab? Siehe mein voriges Post: Mit HTTP GET-Request. Zitieren
AuronX Geschrieben January 14, 2014 at 21:19 Geschrieben January 14, 2014 at 21:19 Siehe mein voriges Post: Mit HTTP GET-Request. Ja klar. Aber was nützt dir das? Was ist das höhere Ziel das du erreichen willst? Also welche Anwendung würde diese HTTP-API nutzen, aber nicht die existierenden Bindings oder die angedachten JavaScript-Bindings nutzen können? Zitieren
Equinox Geschrieben January 14, 2014 at 21:50 Geschrieben January 14, 2014 at 21:50 Also welche Anwendung würde diese HTTP-API nutzen, aber nicht die existierenden Bindings oder die angedachten JavaScript-Bindings nutzen können? Wie schon mehrfach erwähnt, wären damit automatisch alle Sprachen abgedeckt, die HTTP-Requests absetzen können, also auch die, für die es keine Bindings gibt. Desweiteren könnte man ein einheitliches Programmiermodell über all seine Clients völlig sprachunabhängig realisieren und müsste sich nicht mit der Pflege unterschiedlicher Bindings auf all seinen Clients "herumplagen". Zitieren
borg Geschrieben January 14, 2014 at 22:44 Autor Geschrieben January 14, 2014 at 22:44 Dieses "HTTP Request Protokoll" wäre dann aber nur unser ganz normales Protokoll mit mehr Boilerplate. Da sehe ich jetzt auch nicht den Vorteil. Jede Sprache die HTTP Requests absetzen kann, kann auch einen ganz normalen "TCP/IP Socket" nutzen. Zitieren
Loetkolben Geschrieben January 14, 2014 at 23:05 Geschrieben January 14, 2014 at 23:05 Jeder Sprache die HTTP Requests absetzen kann, kann auch einen ganz normalen "TCP/IP Socket" nutzen. wget? Ok,ok,ok. War nicht ganz ernst gemeint. Nur ein bisschen. Also neben der Moeglichkeit zwischen Browser und Hardware direkt zu kommunizieren (via Javascript), faende ich einen Micro "Webserver" charmant der die noetigsten Daten rausgeben kann. Zugegeben, im Moment habe ich aber kein Projekt was das nutzen koennte. Der Loetkolben Zitieren
Stefan Geschrieben January 15, 2014 at 00:38 Geschrieben January 15, 2014 at 00:38 Eine Websocketimplementierung auf dem Brickd und der WiFi-/Ethernet-Extension wäre super. Mit TCP/IP und Websocket müssten nahezu alle Sprachen abgedeckt sein. Einen Art Miniserver könnte sich ja zukünftig jeder mit der On Device Programmierschnittstelle zusammenprogrammieren. Hier sind die Ansprüche viel zu verschieden, der eine möchte JSON, der andere XML... Zitieren
AuronX Geschrieben January 15, 2014 at 08:30 Geschrieben January 15, 2014 at 08:30 Wie schon mehrfach erwähnt, wären damit automatisch alle Sprachen abgedeckt, die HTTP-Requests absetzen können, also auch die, für die es keine Bindings gibt. Desweiteren könnte man ein einheitliches Programmiermodell über all seine Clients völlig sprachunabhängig realisieren und müsste sich nicht mit der Pflege unterschiedlicher Bindings auf all seinen Clients "herumplagen". Wie borg schon sagte können ja all diese Sprachen bereits TCP, also sind sie bereits heute abgedeckt. Das einheitliche Programmiermodell wird doch weitestgehend durch die Bindings erreicht. Das heißt Tinkerforge baut für dich die Bindings die du dann einsetzen kannst um dich nicht darum scheren zu müssen wie die Kommunikation wirklich aussieht. Wenn du tatsächlich dein HTTP-Protokoll nutzen wolltest oder aber das existierende TCP-Protokoll (ich sehe da keinen Unterschied (@Loeti: netcat ^^)), dann müsstest du dich pltzöich selbst um alles kümmern und dir die Abstraktion vom Kommunikationskanal auf deine Programmierumgebung schaffen. Effektiv hast du dann deine eigenen Bindings gebaut. Auf jeden Fall wäre TF damit nicht "automatisch" überall unterstützt. Mit TCP/IP und Websocket müssten nahezu alle Sprachen abgedeckt sein. Sehe ich ebenso Zitieren
Equinox Geschrieben January 15, 2014 at 13:56 Geschrieben January 15, 2014 at 13:56 Hallo, Mit TCP/IP und Websocket müssten nahezu alle Sprachen abgedeckt sein. Klar, aber es ist eine Frage des Komforts, ansonsten hätte man sich ja auch die ganzen Bindings bisher sparen können und nur das Protokoll veröffentlichen können. Die Bindings bieten aber ja wohl eine deutliche "angenehmere" API an. Und so ist es mit HTTP-Requests auch. Es ist doch einfacher einen simplen HTTP-Request abzusetzen (das kann man sogar komplett ohne Programmierung in jedem Browser) als sich die einzelnen Bits und Bytes für das TF-Protokoll zusammenzupfriemeln (das ich mir persönlich noch nicht einmal angeschaut habe). Einen Art Miniserver könnte sich ja zukünftig jeder mit der On Device Programmierschnittstelle zusammenprogrammieren. Hier sind die Ansprüche viel zu verschieden, der eine möchte JSON, der andere XML... Klar, aber das ist ja immer so, auch bei den Bindings haben alle verschiedene Wünsche. Ich würde deshalb der Einfachheit/Realisierbarkeit den Vorrang geben und schlicht und einfach Strings zurückgeben. Damit sollte jeder zurechtkommen. Wenn es noch in XML oder JSON verpackt werden kann, ist das nett, aber aus meiner Sicht kein absolutes muss. Aber bevor wir uns über solche "Details" den Kopf zerbrechen, stellt sich doch die Frage, ob es überhaupt realisierbar wäre. Könnte man also auf dem Stapel so einen Web-Server implementieren (also simpler HTTP-Get Request der einfach nur einen String für den entsprechenden Wert zurückgibt)? Zitieren
borg Geschrieben January 15, 2014 at 14:50 Autor Geschrieben January 15, 2014 at 14:50 Hallo, Mit TCP/IP und Websocket müssten nahezu alle Sprachen abgedeckt sein. Die Bindings bieten aber ja wohl eine deutliche "angenehmere" API an. Und so ist es mit HTTP-Requests auch. Es ist doch einfacher einen simplen HTTP-Request abzusetzen (das kann man sogar komplett ohne Programmierung in jedem Browser) als sich die einzelnen Bits und Bytes für das TF-Protokoll zusammenzupfriemeln (das ich mir persönlich noch nicht einmal angeschaut habe). Das siehst du falsch. Der Master sieht sowas wie "FID=1, UID=xyz, length=20, data=[...]". Die Daten sind absolute Binärdaten, das könnte jetzt 20x uint8 sein, oder 5x uint32 oder nen string aus 20 Zeichen. Mehr Informationen sind nicht da. Natürlich könnte ich jetzt hergehen und die Daten in Base64 kodieren und als Antwort auf ein HTTP Get zurücksenden. Aber das wäre in keinster weise einfacher zu parsen als das was wir aktuell direkt auf den Sockets verschicken. Die Informationen die in den Bindings steckt, nämlich wie der Aufbau der Daten für eine gegebene FID ist, die hat der Master nicht. Zitieren
Equinox Geschrieben January 15, 2014 at 16:00 Geschrieben January 15, 2014 at 16:00 Hallo, Der Master sieht sowas wie "FID=1, UID=xyz, length=20, data=[...]". Die Daten sind absolute Binärdaten, das könnte jetzt 20x uint8 sein, oder 5x uint32 oder nen string aus 20 Zeichen. Mehr Informationen sind nicht da. ... Die Informationen die in den Bindings steckt, nämlich wie der Aufbau der Daten für eine gegebene FID ist, die hat der Master nicht. Klar, dass der Master nicht schön aufbereitete Strings bekommt, die er dann einfach weiterschicken kann, aber könnte man dem Master nicht die Informationen über den Aufbau der Daten für eine FID geben, so dass der Web-Server darauf zugreifen kann und die Daten dann als aufbereitete Strings weitergibt? Deshalb nochmals die Frage: Würde es überhaupt gehen (mit allen notwendigen Änderungen)? Mir ist klar, dass da mehr dahinter sein muss, als ein einfacher Server. Zitieren
raphael_vogel Geschrieben January 15, 2014 at 16:21 Geschrieben January 15, 2014 at 16:21 Die Informationen die in den Bindings steckt, nämlich wie der Aufbau der Daten für eine gegebene FID ist, die hat der Master nicht. Genau daher stelle ich mir das so vor (natürlich vereinfacht ) 1) Portiere die C++ Bindings (oder Teile daraus) auf den Master bzw. auf die WLAN/Ethernet Extension. Dadurch kennt der Master/WLAN den Aufbau der Daten 2) Schreibe einen schlanken Web Server im Master/WLAN/Ethernet 3) Wenn nun ein HTTP Request zum Master kommt (http://master:8080/<brickletID>/getTemperature), dann zerpflückt der Web Server die URL und mit dem Wissen der Bindings ruft er dann die Bricklet Funktion auf. Die Frage ist, ob dafür der Platz auf dem Master/WLAN/Ethernet reicht? Oder hab ich da was komplett falsch verstanden ? Zitieren
borg Geschrieben January 15, 2014 at 17:27 Autor Geschrieben January 15, 2014 at 17:27 Der Master weiß nichts über seine Bricklets. Wenn er das würde, würde er ja auch jedesmal geupatet werden müssen wenn man irgendein Bricklet updatet und es würde eine unglaubliche Menge von Abhängigkeiten geben (Brick Version X.Y funktioniert mit Bricklets Version A.B und C.D und ...). Desweiteren sind alleine die Configs für die Bricklets (also die Beschreibung für die Bindings) 788KB groß, der Master Brick hat 256KB flash. Die Tatsache das die Bricks keine Bricklets kennen müssen macht unser System erst so dynamisch. Ohne wäre das alles uninteressant. Zitieren
raphael_vogel Geschrieben January 15, 2014 at 18:05 Geschrieben January 15, 2014 at 18:05 Ok dann wird das wohl nichts mit den HTTP Abragen direkt gegen den Master. Ich hoffe aber dass zumindest die Web Socket Schnittstelle möglich ist. Zitieren
gunter Geschrieben January 15, 2014 at 23:22 Geschrieben January 15, 2014 at 23:22 Ein bisschen offtopic, aber seid Ihr ganz sicher, dass der O'Reilly Verlag Eure Ankündigung der Perl-Bindings richtig lieb hat? http://shop.oreilly.com/product/9780596004927.do Zitieren
borg Geschrieben January 15, 2014 at 23:42 Autor Geschrieben January 15, 2014 at 23:42 Ich denke die Perl Bindings sind hinreichend nicht-kommerziell das O’Reilly da nichts gegen hat . [...] Das Dromedar ist auf dem Programming Republic of Perl Emblem zu sehen, das oft als offizielles Perl-Logo angesehen wird und dessen nichtkommerziellen Gebrauch O’Reilly gestattet. Zitieren
raphael_vogel Geschrieben January 16, 2014 at 10:08 Geschrieben January 16, 2014 at 10:08 Da muss ich rif recht geben. Wenn man sich mal die Tiobe Liste der am meisten verwendeten Programmiersprachen ansieht (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html), dann sieht man dass TF hier schon ziemlich viel abdeckt. Was aus der top 10 Liste nocht fehlt: Objective-C: Find ich nicht tragisch, da man auf dem Mac auch Java, Python, C#/Mono, C++? usw. verwenden kann. Für's iPhone iPad kann man glaube ich auch die C++ bindings verwenden? JavaScript: Könnte ja bald mit der Unterstützung von WebSockets kommen Von daher finde ich auch die On-Device Geschichte viel wichtiger/interessanter Zitieren
borg Geschrieben January 16, 2014 at 13:42 Autor Geschrieben January 16, 2014 at 13:42 OnDevice/Standalone Diskussionen bitte hier fortführen: http://www.tinkerunity.org/forum/index.php/topic,2127.0.html Ich hab die Kommentare dazu mal gelöscht, dieser Thread ist für neue Bindings . Zitieren
borg Geschrieben January 16, 2014 at 13:44 Autor Geschrieben January 16, 2014 at 13:44 Was aus der top 10 Liste nocht fehlt: Objective-C: Find ich nicht tragisch, da man auf dem Mac auch Java, Python, C#/Mono, C++? usw. verwenden kann. Für's iPhone iPad kann man glaube ich auch die C++ bindings verwenden? Objective-C ist abwärtskompatibel zu C. Man kann also die C/C++ Bindings verwenden. Das tun wir ja auch in unseren iOS Beispiel-Apps. Zitieren
Nic Geschrieben January 16, 2014 at 14:11 Geschrieben January 16, 2014 at 14:11 Ich hab die Kommentare dazu mal gelöscht, dieser Thread ist für neue Bindings Ja verstehe ich, aber gleich die Postings von rif und mir gnadenlos zu löschen ? Verschieben ins neue Thema wäre da etwas diplomatischer gewesen. Zumal ich hier immer noch OnDevice lese Zitieren
borg Geschrieben January 16, 2014 at 14:12 Autor Geschrieben January 16, 2014 at 14:12 Ich hab die Kommentare dazu mal gelöscht, dieser Thread ist für neue Bindings Ja verstehe ich, aber gleich die Postings von rif und mir gnadenlos zu löschen ? Verschieben ins neue Thema wäre da etwas diplomatischer gewesen. Zumal ich hier immer noch OnDevice lese War ja nicht böse gemeint . Im anderen Thread würden die Beiträge ja nichts direkt beitragen und eher verwirren. Zitieren
ufechner Geschrieben February 25, 2014 at 15:15 Geschrieben February 25, 2014 at 15:15 Hallo, ich habe gerade begonnen mich mit Julia (siehe: http://julialang.org/ ) zu beschäftigen. Die Syntax ist ähnlich mit Matlab oder Python, aber die Geschwindigkeit liegt mehr in der Größenordnung von C++. Also: Sehr einfach zu lernen, elegant und schnell. Ist noch ziemlich neu, aber stark im kommen, vor allen an Universitäten. Ich würde mich über Julia- Bindings freuen (vorerst kann man natürlich auch die C-Bindings benutzen, aber das ist doch etwas umständlich). Uwe Fechner, Delft Zitieren
luxor Geschrieben February 25, 2014 at 16:15 Geschrieben February 25, 2014 at 16:15 Ich wünsche mir einfach noch mal Autoit Anbei mal ein Beitrag von länger Zeit von mir. für die kleines Projekt hab ich ein wenig mit Autoit gespielt. Und ich muss sagen ich war sehr angenehm überrascht. Ohne das ich was von der Script Sprache kannte habe ich sehr schnell ein kleines Programm mit GUI und Funktionen erstellt. Ist zwar nur für Windows aber eine GUI Anwendung war wirklich sehr schnell erstellt. Vielleicht wäre das ja mal eine Überlegung wert. Gruß Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.