[Tustep-Liste] Quo vadis? - Die Burg wird zurecht verteidigt

[Thomas Meyer]

Sehr verehrte Damen und Herren,

ohne als Moderator auftreten zu wollen, wird es doch gut sein, auf einer 
grundlegende Unterscheidung zu bestehen:

Es geht in der Diskussion um 
(1.) rechtliche Fragen,
(2.) technische Probleme.


(ad 1.) Der Forderung nach einer vollständigen Freigabe von Tustep ist ohne 
Einschränkung zuzustimmen. Was aus öffentlichen Geldern finanziert wird, muß 
auch von der Öffentlichkeit genutzt werden können. Ohne Wenn und Aber.


(ad 2.) Die Einbindung einer sog. Skriptsprache in Tustep halte ich für 
abwegig und sinnlos. Es müsste eine Entscheidung getroffen werden zwischen 
Python, Ruby, Perl (was mir das Liebste wäre) und anderem. Wenn man dabei 
ist: Sollte man nicht gleich eine Datenbank einbauen (MySQL)? Braucht man 
dann nicht auch PHP? Und ein Grafikprogramm - nehmen wir doch Gimp und bauen 
es ein! - Wer so argumentiert, scheint die Differenz zwischen dem Anspruch 
einer Linux-Distribution und Tustep zu übersehen: erstere erhebt den Anspruch 
auf relative Vollständigkeit, während letzteres einen spezifischen 
Aufgabenbereich abdecken will. Neben Tustep wird es immer gut sein, auf 
seinem Computer außer Windows 95 noch andere Programme zu installieren... 
(Braucht Tustep nicht vielleicht auch einen eigenen Webbrowser und 
Email-client?)

Die Kritik am vielgescholtenen Dateiformat von Tustep zeugt nicht eben von 
tiefgreifenden EDV-Erfahrungen: XML an sich ist für die Haltung großer 
Datenmengen, wie Herr Dr. Trauth zurecht festgehalten hat, ganz ungeeignet, 
weshalb (offene!) Datenbanksysteme wie SQL ausnahmslos auf indexsequentielle 
Datentypen (ähnlich wie bei Tustep) bauen.

Zur Frage der Integration von Tustep und anderen Anwendugen: Darauf, daß 
beliebige Anwendugen zur Arbeit in Tustep aufgerufen werden können, ohne es 
zu verlassen, wurde bereits hingewiesen. Interessanter scheint der umgekehrte 
Fall: Ein gegebenes Projekt setze Werkzeuge außerhalb Tustep ein; nehmen wir 
an, etwa der Editor Emacs sei Hauptwerkzeug. Es ist ein leichtes, aus ihm 
(wie aus jedem anständigen Editor), Systemkommandos zu verschicken. Was 
spricht gegen folgendes Verfahren zur Satzherstellung mit Tustep:

a) Der Benutzer wählt den Menüpunkt "Setzen mit Tustep" :-)
b) Das Tool schreibt den aktuellen Dateinamen in eine Systemvariable und 
c) sendet den Befehl "tustep 999"
d) Die Datei TUSTEP.INI weist Tustep an, die Systemvariable auszulesen, die so 
bekannte Datei nach "Tustep" umzuwandeln, mit #kop zu bearbeiten, mit #satz 
zu setzen, mit #*psaus auszugeben und schließlich die Sitzung wieder zu 
beenden.

Dies setzt beim Benutzer der Applikation keinerlei Tustep-Kenntnisse voraus, 
sondern verlangt lediglich vom Programmierer etwas Phantasie.

Jedenfalls sollte Tustep von einer Festlegung auf eine spezielle 
Skriptsprache, die zufällig das Steckenpferd eines einzelnen ist, 
freigehalten werden - und statt dessen offengehalten für die Fülle von 
Möglichkeiten, die das bisherige offene System bietet. Ganz abgesehen davon, 
daß die Verwendung von der GPL unterstehenden Programmen (wie Perl und 
Python) unter der derzeitigen restriktiven Tustep-Lizenz ein Rechtsbruch 
wäre.


Herzliche Grüße aus Tübingen, Ihr
thomas meyer