Seite 1 von 1
externe Schnittstelle entwickeln
Verfasst: Montag 20. November 2006, 10:53
von george
Hey,
ich soll eine Schnittstelle entwickeln, die das externe Steuern einer Hardwarekomponente ermöglichen soll.
Damit meine ich, ich stelle Funktionalität zur Verfügung, die der Anwender nutzen kann. Die Programmiersprache des Anwenders ist dabei egal(z.B. Visual Basic). Ich muss also eine Schnittstelle zur Verfügung stellen, die sprachunabhängig ist.
Wie würdet ihr dies realisieren? Eventuell als DLL?
Danke
greets george
Verfasst: Montag 20. November 2006, 11:07
von Leonidas
Ich würde es als XML-RPC-Dienst zur Verfügung stellen: Viele Programmiersprachen unterstützen (d.h. haben Libs für) XML-RPC und für die meisten Zwecke reicht es glaube ich auch aus.
Hat auch den Vorteil, dass die Schnittstelle nicht auf dem gleichen Rechner sein muss, und auch nicht das gleiche OS oder gar den gleichen Compiler nutzen muss. Bei einer DLL hast du eben das Problem, dass du unter Linux sofort ausgeschlossen bist. Zusätzlich hast du das Problem, dass du die Schnittstelle erstmal kompilieren musst.
Verfasst: Montag 20. November 2006, 11:35
von gerold
Leonidas hat geschrieben:Ich würde es als XML-RPC-Dienst zur Verfügung stellen:
Hi!
Das kann ich nur unterstützen. Zusätzlich möchte ich aber auch noch ein einfaches Kommandozeileninterface vorschlagen. Allerdings nur, wenn die Kommunikation nur in eine Richtung geht. Also, wenn z.B. einfach nur ein paar Relais geschaltet werden sollen.
Code: Alles auswählen
schalte.py --switch1=on --switch2=off --switch3=on
schalte.py --switch1=off --switch2=on --switch3=off
Wenn es komplexer wird, dann ist ein Dienst (=Service, =Daemon), der per XML-RPC kommuniziert, eine wirklich gute Idee.
Wie ein HTTP-Server, ist so ein XML-RPC-Server komplett unabhängig von der Programmiersprache.
http://www.python-forum.de/topic-5478.html
mfg
Gerold
Edit: HTML-->HTTP
Verfasst: Montag 20. November 2006, 11:39
von Leonidas
gerold hat geschrieben:Wie ein HTML-Server, ist so ein XML-RPC-Server komplett unabhängig von der Programmiersprache.
Kleine Korrektur: HTTP-Server statt HTML-Server
Aber ansonsten hat gerold vollkommen recht, für ganz einfache Sachen eignet sich natürlich ein Kommandozeilenprogramm auch sehr gut.
Verfasst: Montag 20. November 2006, 12:44
von george
Hey,
danke für eure Antworten.
Mit XMLRPC habe ich noch nicht gearbeitet. Werde es mir mal anschauen.
Mir ist an der Stelle noch nicht ganz klar, wie z.B. ein VisualBasic-Client zugreifen kann.
Zwei weitere Alternativen, über die ich nachdedacht habe, sind:
1.) Kleiner Netzwerk-Server mit twisted und TCP/IP
(ich denke, dass XMLRPC so ähnlich funktioniert, oder?)
2.) einen kleinen COM-Server bauen. Habe das folgende Beispiel gefunden
Beispiel
Ich denke aber, dass diese Idee verschiedene Nachteile bietet.
Wie sind eure Erfahrungen hierzu?
greets george
Edit by gerold: URL gekürzt
Verfasst: Montag 20. November 2006, 12:59
von gerold
george hat geschrieben:Mir ist an der Stelle noch nicht ganz klar, wie z.B. ein VisualBasic-Client zugreifen kann.
Hi george!
1.) Wenn du eine Lösung suchst, die nur unter Windows laufen soll, dann solltest du das auch schon bei der Frage dazuschreiben.
2.) "Visual Basic 6" und "Visual Basic.NET" sind zwei paar Schuhe. Welches davon meinst du?
mfg
Gerold
Verfasst: Montag 20. November 2006, 13:03
von gerold
Verfasst: Montag 20. November 2006, 13:06
von george
Hey gerold,
1.) Wenn du eine Lösung suchst, die nur unter Windows laufen soll, dann solltest du das auch schon bei der Frage dazuschreiben.
Sorry. Das Client-OS ist ein Windowssystem.
2.) "Visual Basic 6" und "Visual Basic.NET" sind zwei paar Schuhe. Welches davon meinst du?
Das ist vom Kunden noch nicht eindeutig spezifiziert worden.
Ich muss also so designen, dass die Programmiersprache des Clients eher sekundär ist.
Danke
greets george
Verfasst: Mittwoch 22. November 2006, 00:04
von Leonidas
george hat geschrieben:Mit XMLRPC habe ich noch nicht gearbeitet. Werde es mir mal anschauen.
Mir ist an der Stelle noch nicht ganz klar, wie z.B. ein VisualBasic-Client zugreifen kann.
Über eine Library.
george hat geschrieben:1.) Kleiner Netzwerk-Server mit twisted und TCP/IP
(ich denke, dass XMLRPC so ähnlich funktioniert, oder?)
Ähnlich, aber wesentlich einfacher.
george hat geschrieben:2.) einen kleinen COM-Server bauen. Habe das folgende Beispiel gefunden
Beispiel
Also COM finde ich persönlich nicht so toll - die COM-Unterstützung ist zwar gegeben, aber die Unterstützung für XML-RPC ist Python-Seitens wesentlich besser, sie ist sogar in der stdlib.
george hat geschrieben:
2.) "Visual Basic 6" und "Visual Basic.NET" sind zwei paar Schuhe. Welches davon meinst du?
Das ist vom Kunden noch nicht eindeutig spezifiziert worden.
Ich muss also so designen, dass die Programmiersprache des Clients eher sekundär ist.
COM und XML-RPC erfüllen beide dieses Kriterium. XML-RPC sogar noch mehr, da es mehr XML-RPC Libraties für verschiedene Programmiersprachen gibt, als COM-Libraries.
Wenn du in die
Implementations-Liste auf xmlrpc.com guckst, dann siehst du dort 5 Client und eine Server-Implementation für VB (du brauchst aber sowieso nur Client). Ich muss zugeben, dass ich irgendwann mal aus Spass eine dieser Libraries (comxmlrpc oder vbXMLRPC, das weiß ich nicht mehr genau) aus Python heraus über COM benutzt habe. Und für .NET gibt es auch zwei Libraries (wovon eine allerdings einen toten Link hat).
Verfasst: Mittwoch 22. November 2006, 08:06
von george
Hey Leonidas,
danke noch einmal für deine ausführliche Antwort und den Hinweis zu den Beispielen.
Ich denke, dass ich es als XMLRPC entwickeln werde(wie auch von gerold geraten).
Danke
greets george
Verfasst: Mittwoch 22. November 2006, 19:30
von dev
Leonidas hat geschrieben:
george hat geschrieben:1.) Kleiner Netzwerk-Server mit twisted und TCP/IP
(ich denke, dass XMLRPC so ähnlich funktioniert, oder?)
Ähnlich, aber wesentlich einfacher.
Wieso eigentlich
wesentlich einfacher? (Mal abgesehen davon, daß wir hier gerade quer durch die Schichten vergleichen.)
http://www.python-forum.de/post-46983.html#46983
Mir liegt fern hier einen Glaubenskrieg vom Zaun zu brechen, mich würde nur interessieren, wieso nahezu immer, wenn der Begriff
Twisted fällt, sofort Kreuze, Weihwasser und Knoblauch gezückt werden.
Ich beobachte Twisted seit mehreren Jahren und nutze es seit nunmehr zwei Jahren exzessiv für meine Projekte.
Wobei ich zugegebenerweise viele Bereiche des Frameworks auf Grund dessen schieren Umfangs noch nicht genutzt habe.
Ich würde es aber auf jeden Fall nicht mehr missen wollen.
Liegt es vielleicht an den Deferreds?
An der Idee threads zu vermeiden?
An der Dokumentationssituation?
Ciao,
dev
Verfasst: Mittwoch 22. November 2006, 21:33
von Leonidas
dev hat geschrieben:Wieso eigentlich wesentlich einfacher? (Mal abgesehen davon, daß wir hier gerade quer durch die Schichten vergleichen.)
Aus mehreren Gründen: es ist mitgeliefert (man muss also nicht Twisted rauspacken, weil es schon seit langem in der stdlib ist), es ist gut dokumentiert. Verlutlich ist auch der Quelltext einfacher verständlich, weil es einfacher gestrickt ist als das Framework Twisted.
Zugegeben, simpel. Das ist
SimpleXMLRPCServer aber auch.
dev hat geschrieben:Mir liegt fern hier einen Glaubenskrieg vom Zaun zu brechen, mich würde nur interessieren, wieso nahezu immer, wenn der Begriff
Twisted fällt, sofort Kreuze, Weihwasser und Knoblauch gezückt werden.
Hehe
Twisted hat halt so den Ruf die Kanone für Spatzen zu sein.
dev hat geschrieben:Ich beobachte Twisted seit mehreren Jahren und nutze es seit nunmehr zwei Jahren exzessiv für meine Projekte.
Wobei ich zugegebenerweise viele Bereiche des Frameworks auf Grund dessen schieren Umfangs noch nicht genutzt habe.
Ich würde es aber auf jeden Fall nicht mehr missen wollen.
Das ist doch wunderbar - ich habe nicht behauptet, das Twisted schlecht sei. Nur fand ich die Arbeit mit Twisted Words eher unangenehm, da sich die Twisted IRClib komplett anders verhalten hat als die Twisted Jabber-Lib und diese wieder komplett anders als xmpppy.
Nun, dev, sag selbst: würdest du, um mal schnell eine Schnittstelle herzustellen, Twisted verwenden, mit dem Wissen, dass man dann Twisted extra installieren muss, obwohl die stdlib das gleiche bietet? Nein, es geht um eine einfache Schnittstelle, nicht um einen Server mit tausenden Requests pro Minute.
Verfasst: Donnerstag 23. November 2006, 08:05
von george
Hey,
würdest du, um mal schnell eine Schnittstelle herzustellen, Twisted verwenden, mit dem Wissen, dass man dann Twisted extra installieren muss, obwohl die stdlib das gleiche bietet? Nein, es geht um eine einfache Schnittstelle, nicht um einen Server mit tausenden Requests pro Minute.
Da muss ich Leonidas recht geben. Bedingt durch die Einfachheit, werde ich es, wie bereits erwähnt, als xmlrpc implementieren.
Ich beobachte Twisted seit mehreren Jahren und nutze es seit nunmehr zwei Jahren exzessiv für meine Projekte.
Wobei ich zugegebenerweise viele Bereiche des Frameworks auf Grund dessen schieren Umfangs noch nicht genutzt habe.
Ich würde es aber auf jeden Fall nicht mehr missen wollen.
Da kann ich dev nur zustimmen. Ich habe, basierend auf twisted, einen Datenserver zum Pollen von elektronischen Geräten entwickelt und war begeistert über dieses Framework.
Ich muss aber auch gestehen, dass das Framework recht komplex ist und es sicherlich einen gewissen Zeitrahmen in Anspruch nimmt, um es einigermaßen zu verstehen.
greets george