Hi,
Volker Heggemann schrieb:
...
Ohne die einfache Möglichkeit, an Testversionen zu kommen, werden sich
keine Tester finden.
Ich denke Testversionen kann und wird es nicht geben.
Warum?
Mal abgesehen von vielleicht den Extensions die Sun bereit stellt.
Und genau um so eine geht es hier. Wobei die genaugenommen nicht einfach
nur "von Sun bereitgestellt" wird, sondern im ganz normalen
Code-Repository von OOo liegt und Bestandteil des Gesamtprojektes ist.
Wieso sollten für diese Extension deutlich geringere Qualitätskriterien
gelten, als für den Rest von OOo?
(Und einige andere "Große") Sind die Extension meisten von jemandem
für ein eigenes persönliches Problem geschrieben.
Jepp .. um die geht es mir auch weniger.
Was nocht heisst, dass möglicherweise andere Autoren den gleichen
Mechanismus nutzen können, wie das OOo-Projekt selbst, um Extensions zu
testen (testen zu lassen). Nur wenn wir das noch nichtmal für unsere
Extensions tun ...
Das kann dann ja auch noch in 3 oder 5 verschiedenen Prog. Sprachen
(Phyton, Java, Starbasic...)
Hmmm? Neee
und verschiedenen Sprachversionen geschehen. Die Menschen denken sich
dann: "Ok, das kann ja vielleicht noch jemand anderes gebrauchen -
ich pack es in eine Extension und stelle es bereit." Ob das dann in
jedem Einzelfall unter allen Office Versionen und Betriebs-
systemen funktioniert ist eine andere Frage.
Ich meine - schön, das das so klappt und das es ne Möglichkeit gibt
Openoffice zu erweitern. Sollte man Probleme mit
einer Extension haben, schreibt man am besten an den Verfasser. Dann
kann dieser das auf der Internetseite der Extension
als hinweis aufführen, oder seine Erweiterung anpassen.
Aber das ist doch gerade die Idiotie: im Moment gibt es keine
öffentlichen Testversionen. D.h.der Kreis der Tester ist erzwungen
eingegrenzt. So *kann* es definitiv nicht funktionieren, auf
verschiedenen Plattformen zu testen. "Not possible by Design".
Mit einer Möglichkeit, Testversionen herauszugeben, könnte man diverse
Probleme in Produktivumgebungen vermeiden helfen.
(Aber ich weiß auch, dass du shcon oft genug drauf gedrängt hast, dass
Extension besser getestet werden sollten und auch bessere Möglichkeiten
dafür gescvhaffen werden sollten. Das alles ist also nicht Kritik
an Dir - bitte nicht missverstehen.)
Eine ggf. gegebene Inkompatiblität von Extension mit anderen Versionen
der Software oder einem Betriebssystem liegt
auch ein wenig ander nicht ganz trivialen UNO Schnittstelle.
Jein. Es liegt evtl. daran, dass der Entwickler die Vorhandenen
Spezifikationen und Dokumentationen nicht beachtet, dass diese
unvollständig oder fehlerhaft sind, dass die aktuelle Implementierung in
OOo fehlerhaft ist oder dass sich dokumentierte Funktionen ändern.
Wenn man z.B. abfragen will welches Betriebssystem, welche Openoffice
Version und welche Art von Dokument gerade offen ist,
auf das man gerne eine Makro anwenden will, dann sind laut UNO-API
schon die ersten 30 Zeilen Code geschrieben.
Die Menge an Code hat doch aber nichts mit der Stabilität einer
Software-Schnittstelle zu tun. Wenn die Schnittstelle stabil wäre,
würden die gleichen Codezeilen
heute wie in hundert Jahren funktionieren.
Selbstverständlich wird eine API kaum "ewig" unverändert bleiben - im
Moment haben wir aber (meines Wissens) nicht ansatzweise Konzepte, APIs
als veraltet (bzw. "ändert sich demnächst") zu kennzeichnen und damit
dem Extension-Autor ein Gefühl zu geben, wie lang seine Extension noch
funktionieren könnte.
Sowas zu konzipieren hat nicht nur was damit zu tun, dass Anwender dann
keine kaputten Extensions bekommen - das bietet auch eine erhöhte
Planungssicherheit für Entwickler. (Ich würde dazu - wenn du die Chane
hast - ein Fachgespräch oder einen Vortrag der Wollmux-Entwicklern
empfehlen.)
Gruß,
André
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org
For additional commands, e-mail: dev-h...@de.openoffice.org
