[Python-de] David Beazleys Buch auf Deutsch!

Martin v. Loewis martin at loewis.home.cs.tu-berlin.de
Thu Sep 28 21:02:19 EDT 2000


> Hier hat sich in letzter Zeit viel getan... sind die Änderungen
> alle in dem Buch erfaßt (allein zwischen den 2.0 betas ist einiges
> geändert worden) ?

Wir haben sowieso keine vollständige Liste aller Funktionen. Die
*Änderungen* haben wir alle, denke ich, wie auch alle "wichtigen"
Funktionen (nach unserer subjektiven Einschätzung, natürlich).

> Welches Interface ist z.Z. eigentlich für CORBA zu empfehlen ?

Der Clue an CORBA ist die Portabilität - egal, ob man für ILU, Fnorb,
omniORB oder orbit-python schreibt: Der Portierungsaufwand ist gering
(auf dem Client idealerweise null, bis auf andere imports; auf der
Serverseite gibt es Änderungen, da nur omniORB den "Portable Object
Adapter" unterstützt).

Aus der Sicht "einfach zu installieren" würde ich immer noch Fnorb
empfehlen; es hat ein einziges C-Modul (genauer: zwei einzige :).
Leider steht die Zukunft von Fnorb in den Sternen, und es ist keine
"freie Software" (im GNU-Sinne freier Rede).

Aus Sicht "Vollständigkeit, Unterstützung durch Entwickler,
Performanz" liegt gegenwärtig omniORBpy vorn - wenn man erstmal die
Übersetzungsorgie des C++-Teils hinter sich hat, oder gleich die
Binaries benutzt.

> Un wie stabil laufen die Interfaces ?

Sehr verschieden. Fnorb hatte die Angewohnheit, Typtests auszulassen
(PyString_Check); man konnte es also mit falschen Typen leicht in die
Knie zwingen - inzwischen ist das korrigiert. Bei ILU, Fnorb und
omniORB gibt es wohl nur noch wenig ernste Bugs. Die ORBit-basierten
Versionen scheinen mir eher Unvollständig.

Neben Stabilität ist in CORBA auch die Interoperabilität spannend; das
letzte ernsthafte Interoperabilitätsproblem hatte ich vor einem Jahr.
Interessanterweise tauchen neuerdings Probleme mit der "Code Set
Negotiation" auf (nicht nur bei den Python-ORBs), nachdem die ORBs
anfangen, die OMG-Specs zu dem Thema auch tatsächlich zu
implementieren.  

Falls sendender und empfangender ORB sich nicht auf einen Zeichensatz
einigen können, scheitert die Kommunikation. Das Problem bestand
darin, das ORBacus als wstring-Zeichensatz UCS-2 angeboten hat, ILU
aber nur UTF-16 akzeptiert hätte...

> Vielleicht habt Ihr ja auch Interesse an den mxCGIPython Versionen
> für 2.0. Ich plane ein Neuauflage des doch recht erfolgreichen
> Projekts für 2.0.

Ich muss gestehen, dass ich erstmalig davon höre - sieht aber wie eine
tolle Sache aus! Wenn Du eine Erzeugungsprozedur fertig hast, kann ich
gerne Solaris-2.6- und Solaris-8-Versionen beisteuern.

Ciao,
Martin




More information about the Python-de mailing list