Jörg Schmidt schrieb: > Hallo *, > > michael schrieb: >> Die API ist im Übrigen sehr "konservativ", d.h. was einmal eingeführt >> worden ist, wird, wenn eben möglich, beibehalten. Es wird etwas >> hinzugefügt, aber, wenn eben möglich, nichts weggenommen. sodass alte >> Programme auch unter neuen OpenOffice.org-Versionen laufen >> (wenn nicht, >> wäre das ein Bug). >> >> OpenOffice.org möchte die Investitionen seiner Anwender (Zeit, >> Programmierkunst oder Geld) möglichst schützen. > > So sollte es sein, ist es aber leider in Praxis längst nicht immer. > In neueren OOo-Versionen (ca. ab OOo 2.0) ist man bei > Makroprogrammierung im Allgemeinen darauf angewiesen Makros > OOo-versions-spezifisch zu testen und freizugeben um die Funktion der > Makros garantieren zu können. > Ich würde mal schätzen das bei größeren OOo-Nutzern (größere Firmen oder > größere Projekte der öffentlichen Hand) inzwischen bestimmt mehr als 15% > Kosten zu den eigentlichen Kosten für die Makros (normale > Programmierung, Testen, Wartung, allgemeiner Support) hinzukommen, > welche nur aufgewendet werden müssen um Testszenarien zu entwerfen, > Tests durchzuführen und workarounds zu realisieren, welche in Summe nur > dazu dienen API-Probleme aufzufangen. > > Das wird Dir so ähnlich jeder sagen der mit diesen Dingen befasst ist. > Frage z.B. Thomas (mit dem ich u.A. seit Längerem bei einem größeren > Migrationsprojekt zusammmenarbeite) oder frage Michael Dannenhöfer > (StarBasic-FAQ) oder frage jeden der beruflich StarBasic programmiert. > > UNd wie sollte es auch anders sein wenn wir doch seit Längerem gemeinsam > beklagen das wir es nicht schaffen hinreichend schnell gemeldete Fehler > in OOo zu fixen, entsprechende Probleme gibt es nun einmal auch bei der > API. >
Es ist der allgemein festzustellende Unterschied zwischen Sein und Sollen. Dieser wird bei Software als "Bug" bezeichnet. Bei der API kommt noch hinzu, dass IMO Fehler zu oft nicht gemeldet werden und, wenn sie gemeldet werden, nicht hinreichend eskaliert werden. Hier erscheint mir die Kommunikation zwischen "Betroffenen", QA und Entwicklern noch verbesserungsbedürftig. Gruß Michael --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
