Welche Sprachen/Technologien Nutzen?
-
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.