M
knivil schrieb:
Also es geht um Plattformunabhaengigkeit? Welche Probleme entstehen? Tja natuerlich mit Plattformabhaengigkeit. Deswegen habe ich nach Beispielen gefragt, um "Und von OS-Features die die Bilbiothek nicht unterstützt und die man dann von Hand machen muss. Für jede Plattform" besser zu verstehen. Leider habe ich es richtig verstanden, es hat nichts mit dem Thema zu tun. Wenn man "plattformunabhaengig" sein moechte, so kann man nur Features verwenden, die auf allen Plattformen durch Bibliotheken angeboten werden. Deswegen verstehe ich den Einwand nicht.
Im Grunde hast du Recht, wenn ich deine Aussage richtig verstehe. Mir geht es mehr um die Frage, welche Probleme man generell hat, wenn man komplexe Software für mehrere Plattformen anbieten will. Es scheinen nämlich viele zu glauben, es würde reichen, einfach mal ein paar plattformunabhängige Bibliotheken wie Qt zu nehmen, einfach auch für die andere Plattform zu kompilieren und das wars. Ich war eigentlich eher schon immer der Meinung, und fühle mich durch unser Projekt auch in der Meinung bestätigt, dass es bei jeder halbwegs komplexen Software überhaupt nicht so einfach ist und extrem viel Arbeit auf einen zukommt. Und mir gehts hier auch nicht grundsätzlich um Windows Technologien, die auf Unix nicht verfügbar sind, ich sehe das Problem in der anderen Richtung genauso. Wäre Unix die primäre Plattform, wärs genauso schwer, einen Windows Port zu pflegen.
Ich wollte eigentlich nicht, dass die Diskussion zu einer D-Bus Diskussion ausartet, ich finde das alles eher offtopic. Aber um das vielleicht abzuschließen... Nein, wir würden D-Bus wahrscheinlich nicht nehmen und Python hat damit jetzt recht wenig zu tun. D-Bus ist eine IPC Technologie, COM ist eine Komponenten-Technologie, das ist nicht wirklich das gleiche. Mit COM kann man einfach ein Application Model anbieten, und Objekte und Komponenten, die exerne verwenden können. Das ist auch das, was wir eigentlich wollen. Das ist so ähnliche, wie wenn man sich aus einem Script heraus ein Outlook.Application besorgt (oder wie auch immer), sich dann durch die Objekte durchhangelt, neue Objekte erstellt, usw. So ein ähnliches Application Model bieten wir auch an, nur wesentlich umfangreicher als Outlook. Ich könnte mir auch vorstellen, wie man das mit D-Bus lösen könnte, quasi über virtuelle Adressräume und die Objekte würden im Endeffekt nicht in der Client Anwendung leben sondern in der "Serveranwendung". Aber das ist nur theoretisch etwas ähnliches, es ist wie gesagt nicht das, was wir eigentlich wollen und so wirklich passt das einfach nicht. Und wie ich schon gesagt habe, ich kann mir nicht vorstellen, dass man aus AutoLisp (zumindest ohne weitere Verrenkungen) D-Bus ansprechen kann. COM Objekte kann man in AutoLisp hingegen sehr wohl sehr einfach erstellen.
