Zitat von
tommie-lie:
Zitat von
mh166:
Afaik gibts das aber nicht nativ für Linux, oder täusch ich mich? Aber ich kann ja auf das
Mono-Framework zurückgreifen, für Linux.
Definiere "nativ" in Zusammenhang mit dem .NET-Framework
Mono ist so nativ wie Microsofts Framework auch.
Damit mein ich, dass M$ selber
IMHO kein .NET für *nix zur Verfügung stellt und ich deshalb auf Mono zurückgreifen müsste. Soll heißen "nativ" = "von M$".
Das Problem, was ich mit .NET hab ist halt, dass ich a) damit noch nich gearbeitet habe, b) nich weiß, inwieweit man W32-Kompos in .NET verwenden kann oder obs die Indys auch für dN gibt und c) keine Ahnung habe, inwieweit dann Mono das compilat fehlerfrei und vor allem auch als Deamon ausführen kann.
Zitat:
Zitat von
mh166:
Jetzt also meine Frage: ist das Ganze Unterfangen überhaupt möglich und wenn: was sollte man dabei beachten? Welche Delphi-/Kylix-Versionen sind dafür am Besten geeignet (wegen Kompatibilität zw. den beiden)?
Es ist sicherlich möglich, Delphi kennt IFDEFs genauso wie jede andere vernünftige Sprache auch
Die Gegenversion zu Kylix3 ist mehr oder weniger Delphi 6.5, mit Delphi 6 oder Delphi 7 solltest du also Glück haben (ist ja gut, ich geh' gleich in die Ecke und schäme mich dafür, "Kylix" und "Glück" im gleichen Satz verwendet zu haben).
Thx. Werd mal sehen, wo ich Kylix3 herbekomme...
Zitat:
Zur Plattformunabhängigkeit deiner Plugins: Wenn du die Plugins nicht komplett selbst interpretieren willst, müssen diese ebenfalls portabel sein. Klassisch implementiert man Plugins unter Windows mit DLLs, unter Linux wäre das Äquivalent dazu ein SO, komplett anderes Dateiformat.
Ich nehm an, du meinst, dass die plattformunabhängig sein müssen, weil ich die ja erst laden muss. Ich hab aber vor die Schnittstelle so zu realisieren, dass eine "Parameterdatei" dazu mitgeliefert werden muss, in der dann unter anderem auch die Zielplattform drin steht, so dass ich im Prinzip nur die Textdatei öffnen muss, um zu sehen ob das Plugin geladen werden kann.
Zitat:
Außerdem dürfen die Plugins nicht auf Funktionen des Betriebssystems zurückgreifen, bzw auf eine
RTL, die nur auf einem System zur Verfügung steht. Im Falle von C(++) wären sie strikt auf die stdlib (STL) beschränkt.
Hmm... was kann man denn da im Falle von Kylix und Delphi sicher verwenden und von was sollte man die Finger lassen?
Zitat:
Die Indies gibt es soweit ich weiß auch für Kylix, du könntest also für den Daemon mit der gleichen Codebase für Linux und Windows arbeiten, wenn du dich geschickt anstellst (Tipp: Daemons haben i.d.R. keine
GUI ).
Das klingt schon mal gut.
GUI war ja auch nur als Webinterface geplant, deshalb auch die Indys.
Zitat:
Mit irgendwelchen Servern und Plugins schreit das ganze für mich allerdings für ein transparentes System, ergo .NET oder Java, wenn's denn sein muss. Wirklich gescheite native Lösungen fallen mir für sowas fast gar nicht ein.
Womit wir wieder bei dem Thema dotNET vs
win32-Kompos wären.
Und wegen der Lösung durch PHP: Der Server ja als Dienst/Deamon auf jedem Rechner im LAN eingesetzt werden und dann durch Weboberfläche und entsprechende Plugins die Funktionen/Informationen bereitstellen. Soll heißen: PHP und/oder Ajax fallen als Lösung raus.
Danke schon mal für die Antworten
mfg, mh166