Welche Sprachen/Technologien Nutzen?
-
Folgendes Szenario:
eine Client-Server-Applikation, wo im Client ein Quellcode eingegeben wird der auf dem Server compiliert/interpretiert werden soll.
Das Clientprogramm soll aus einer GUI bestehn mit einem Texteingabefeld und eventuell einer eingebauten Syntaxprüfung (könnte man aber auch an den Server delegieren). Auf dem Server soll dann der Compiler/Interpreter laufen.Meine Frage jetzt: was benutz ich am Besten für den Client, was für den Server?
Mir schwebt zur Zeit vor, den Client in Java zu schreiben und den Parser/Syntaxprüfer auf Serverseite zu lassen, so dass man den Client in anderen Sprachen (z.B. HTML/PHP) schnell dazuschreiben kann.
Für den Parser schwebt mir boost::spirit vor, die Umsetzung des Compilers ebenfalls in C oder C++.
Über die Verbindung werden je nachdem wohl Klartext (Parser auf Serverseite) oder sowas wie ein Syntaxbaum (Parser auf Clientseite) geschickt, gibts da spezielle Technologien um sowas umzusetzen (vor allem letzteres)?
Gibts alternative Sprachen die ihr für die einzelnen Teile vorschlagen würdet?
-
In welcher Sprache soll der Code auf dem Client geschrieben werden?
-
ist doch eignetlich für die Frage nicht von Belang oder? Das ist ne eigene Sprache, dehalb ja auch der selbstgeschriebene parser.
-
etwas ähnliches ist mir vor ein paar wochen auch durch den kopf gegangen. allerdings nicht der editier-teil, sondern eher der buildschritt. meine idee war es, auf clientseite normal zu editieren und source zu speichern und auf server seite unter linux zu kompilieren (also ähnlich distcc, nur etwas generischer um auch andere tools zum laufen zubringen, wie z.b. auch den msvc compiler unter wine). bin also offen für ideenaustausch via email
-
pumuckl schrieb:
Gibts alternative Sprachen die ihr für die einzelnen Teile vorschlagen würdet?
Hm. Client und Server sind ja anscheinend relativ trivial und sollten in der Sprache sein, mit der du das schnell entwickeln kannst, für den Client hast du dich ja anscheinend schon für Java entschieden.
Das Einzige, was dann noch bleibt, ist/sind Compiler/Interpreter. Da das ja recht knifflig werden kann, würde ich das in der Sprache basteln, in der ich am besten arbeiten kann.
C++ bietet sich an, weil's dafür immerhin schon einige Tools und Ressourcen gibt, allerdings weiß ich auch nicht, wie groß die Code- und Toolbasis für Compiler in Java o.Ä. ist.Btw: Ich hab auch mal ein gutes Jahr lang einen Compiler geschrieben (war auch halbwegs lauffähig), das Ganze war in C++. Ich hatte aber das Gefühl, dass sich Compiler (jedenfalls meiner) mit dem Java-/C#-Zeigerkonzept besser umsetzen lassen.
-
wenn du sogar eine webseite als client verwenden willst, würde sich etwas http-basiertes als transportprotokoll anbieten. soap oder rest zb. die programmiersprachen sind dadurch relativ egal, da wohl für jede sprache eine passende bibliothek vorhanden wäre.
@Badestrand
darf man deinen compiler auch mal ansehen?
-
besserwisser schrieb:
darf man deinen compiler auch mal ansehen?
Den Quellcode? Ich fürchte, den willst du nicht sehen, ich hab das Projekt nie richtig abgeschlossen, entsprechend sehen Teile noch nach Baustelle aus
Ich plane aber noch, bei Gelegenheit weiterzumachen, wenn's sauberer ist, könnte ich mal nen Thread in "Projekte" aufmachen oder dir per Mail schicken.edit: Sooo schlimm sieht er doch nicht aus, bei Bedarf schick ich ihn dir gerne
-
Hallo, erstmal danke für die Anregungen!
Ich habe mich jetzt entschlossen, den Client erstmal möglichst dünn zu gestalten, soll heißen einfach den eingegebenen Text in einem plattformunabhängigen Format an den Server zu schicken, wo dann die weitere Verarbeitung stattfindet. Folgende Möglichkeiten schweben mir vor, wie man den Client umsetzen könnte:- als eigenständiges Programm, geschrieben in C, C++, C#, Java, ... es muss sich ja nur mit dem Server verbinden und den eingegebenen Text (evtl entsprechend verpackt) verschicken und ggf. Rückmeldungen vom Server entgegennehmen.
- als Java-Applet (sollte keinen Unterschied machen)
- als Webseite in PHP, ggf. mit JavaScript etc. hier baut dann der Webserver die Verbindung zum Sprachserver auf.Was noch zu klären bleibt ist das Format. Leider bin ich in solchen Dingen nicht so bewandert, was die Kommunikation über Sockets etc angeht, mir stellen sich z.B. folgende Fragen:
- auf verschiedenen Plattformen/Compilern kann ein C++-Char mal Vorzeichenbehaftet sein, mal nicht. Wenn ich Klartext zwischen zwei derart verschiedenen Systemen austausche, muss dann eine Umwandlung geschehen?
- chars in Java sind 2 Byte groß, in C++ ein Byte - wenn ich also Client in Java und Server in C++ habe, muss dann auch eine Umwandlung der einzelnen zeichen erfolgen?Eine Vorüberlegung von mir war, den Quellcode bis zu einem gewissen Grad in XML zu "verpacken" und erst dann zu verschicken - das ergibt dann zwar etwas mehr Traffic aber das sollte bei heutigen Verbeindungsgeschwindigkeiten nicht weiter ins Gewicht fallen. Vermutlich gibt es für diverse Sprachen XML-Bibliotheken, aber sind die auch alle zueinander kompatibel?
Sry für mein Unwissen...
-
pumuckl schrieb:
Vermutlich gibt es für diverse Sprachen XML-Bibliotheken, aber sind die auch alle zueinander kompatibel?
Solange die Bibliotheken valides XML schreiben und lesen können: Klar!
Xml halte ich in deinem Fall für die Übertragung für eine sehr gute Wahl.
-
Warum? XML ist für strukturierte Daten gedacht, wo ist hier die Struktur? IMHO ist das völlig unnötiger Overhead.
Ich würde den Text als solchen übertragen, als Verbindung ein simples HTTP Post nehmen, da kommt AFAIK auch das Encoding mit. Einen kleinen HTTP-Server in deinen Server zu integrieren sollte auch kein Problem darstellen.
-
.filmor schrieb:
Warum? XML ist für strukturierte Daten gedacht, wo ist hier die Struktur? IMHO ist das völlig unnötiger Overhead.
Quellcode ist in der Regel doch strukturiert. Wir haben keine Details, aber selbst wenn die einzige Strukturierung darin besteht, dass der Quellcode aus mehreren Dateien besteht, haben wir schon eine.
-
Solange der Quellcode selber nicht XML ist...
-
XML---- schrieb:
Solange der Quellcode selber nicht XML ist...
auch das wäre kein problem.
soap oder rest sind hier eine passende wahl - weil es eben standardtools gibt um die entwicklung zu erleichtern
-
Shade Of Mine schrieb:
XML---- schrieb:
Solange der Quellcode selber nicht XML ist...
auch das wäre kein problem.
Technisch nicht. Aber wenn der Quellcode tatsächlich von einem Anwender eingegeben wird, ist XML als Format sicherlich eine schlechte Wahl -- siehe das Build-Tool Ant. Ich kenn zwar das Problem den OP nicht, aber eine DSL basierend auf einer Skriptsprache wäre ein Lösung, über die man nachdenken kann.
-
Der Quellcode hat eine C++/Java-ähnliche Syntax.
Mir ist klar, dass für einen Transfer in XML-Form der eingegebene Code eine gewisse Struktur haben müsste, was wiederum bedeutet dass ich zumindest bis zu einem gewissen Grad auf Client-Seite parsen muss.Wenn beim HTTP-POST das Encoding mitkommt sollte das wohl kein Problem darstellen den Text so wie er ist zu verschicken. Wenn ich das richtig sehe wären dafür folgende Voraussetzungen ideal:
- Eine Möglichkeit für das Encoding in jeder Sprache in der der Client geschrieben werden können soll.
- Möglichkeiten für Decoding (für alle verschiedenen Encodings) in der Sprache auf Serverseite.
-
ich wuerde das viel simpler machen, auf dem server ein ftp service, auf dem client diesen als laufwerk mappen und dann mit jedem belibigen editor darauf arbeiten. auf dem server ein hook aufs gemappte laufwerk und wenn sich eine datei aendern, make starten.
-
rapso schrieb:
ich wuerde das viel simpler machen, auf dem server ein ftp service, auf dem client diesen als laufwerk mappen und dann mit jedem belibigen editor darauf arbeiten. auf dem server ein hook aufs gemappte laufwerk und wenn sich eine datei aendern, make starten.
Wenn ich das richtig verstanden habe lade ich damit sozusagen Dateien mit dem Quelltext vom Client auf den Server hoch, wo der Server sie dann verarbeitet. Mal abgesehen davon dass kein make gestartet wird sondern der Code von einem durchgehend laufenden Daemon konsumiert und verarbeitet wird ergeben sich da auf den ersten Blick folgende Probleme:
- ich habe auf die Weise keine Möglichkeit, Rückmeldungen vom Server (z.B. Kompilierfehler) an den Client zu schicken
- da natürlich Clients von verschiedensten Plattformen zulässig sein sollen, habe ich dann Dateien in diversen Character-Encodings auf dem Server liegen, ganz zu schweigen von einem Mischmasch aus UNIX- und Windows-Zeilenumbrüchen etc.Natürlich soll es möglich sein, auch fertig editierte Dateien an den Server zu schicken, ohne den Inhalt per C&P in ein Texteingabefeld zu stopfen, allerdings schwebt mir dazu eher vor, die Dateien vom Client öffnen zu lassen und ihren Inhalt entsprechend formatiert an den Server zu schicken.