Zitat:
Original erstellt von marc.scherer:
Hi,
zum Thema LDATA gab es doch schon mal 'ne ellenlange Diskussion?
Da hatte der von uns allen geschätzte Axel 'ne eindeutige Meinung zu oder? http://ww3.cad.de/foren/ubb/Forum145/HTML/000830.shtml#000005
Rainer, kannst Du mal 'ne DWG mit solchen LData uppen?
Würde gerne mal wissen, ob ich mit meinem Dictionary-Leser an Deine LData rankomme und somit eventuelle vlax-ldata-list überflüssig wäre.
Der gute Axel hat da im Wesentlichen meine Erfahrungen weiter gereicht, die darauf hinaus liefen, dass LDATA ein absolutes NoNo sind.
Da kamen mehrere Fehler zusammen. LDATA waren bei ihrer ersten Implementierung in R14 an persistente Reaktoren geknüpft (die also fest in der DWG gespeichert wurden), die bei fehlender Anwendung dann beim Öffnen der DWG mindestens jede Menge Proxy-Elemente meldeten (eine Meldung für jedes LDATA-Element, und das konnten Tausende sein!), die aber auch schon mal wild Amok liefen.
Endgültig desavouriert wurden die LDATA beim Umstieg auf A2K - die LDATA in R14 waren nämlich mit einem Applikationsnamen für R14 verknüpft und konnten in A2K weder ausgelesen noch gelöscht werden, brachten dabei aber immer die Proxy-Meldungen. Eine einmal in A2K gespeicherte DWG aber konnte in R14 nicht mehr geöffnet werden, so dass diese amoklaufenden Dinger nicht mehr entfernt werden konnten! Die damit verknüpften persistenten Reaktoren liefen dann auch wirklich Amok und zerstörten schleichend die DWG-Datei. Das äußerte sich zunächst in immer häufiger auftretenden Abstürzen, bis irgend wann die DWGs sich gar nicht mehr öffnen liessen.
Dummerweise hatte ich für meine Applikation ArchTools die LDATA in R14 ziemlich ausgiebig benutzt, und nach dem Umstieg auf A2K führte das bei einem meiner größeren Kunden zu der beschriebenen Zerstörung der DWG-Dateien. Alleine bei dem einen Kunden waren etwa 70.000 Zeichnungsdateien betroffen, im Durchschnitt stellte jede einen Wert von etwa 10.000 bis 20.000 DM dar - also potentiell ein Schaden von etwa einer Milliarde DM.
Der Kunde wandte sich damals an Autodesk, und die sandten einen Mitarbeiter dort hin, der nach einigen Tagen meldete: die Ursache der Fehler sei in ArchTools zu suchen. Ich erhielt darauf hin eine Abmahnung von Autodesk mit der Aufforderung, den Vertrieb meines Programms einzustellen und alle verkauften Lizenzen zurück zu ziehen. Von meinem Kunden erhielt ich die Aufforderung, seine 70.000 DWGs zu sanieren.
Glücklicherweise gelang mir unter Mithilfe von Autodesk Mitarbeitern (die damit gegen Anweisungen Autodesks verstiessen!) der Nachweis, dass die Ursache dieses Problems nicht in meinem Programm steckte, sondern in der fehlerhaften Implementierung der LDATA begründet war. Das Fehlverhalten der LDATA konnte ich mit einem syntaktisch völlig korrekten LISP-5-Zeiler reproduzieren. Autodesk hat diesen Fehler bis heute nicht zugegeben und sich auch nicht bei mir entschuldigt!
Später erfuhr ich von dem zu meinem Kunden abgestellten Autodesk Mitarbeiter, dass er - wider besseren Wissens - von seinem Vorgesetzten aufgefordert worden ist, die "Ursache" des Problems meinem Programm zuzuschreiben. Dieser Mitarbeiter hat nach einigen Tagen Bedenkzeit fristlos bei Autodesk gekündigt, mein Kontakt zu ihm kam buchstäblich auf sehr abenteuerliche James-Bond-Manier zustande, deren Details den Rahmen hier sprengen würde.
Wer eine unabhängige Meinung zu dieser Geschichte einholen will, der kann sich z.B. an Reini Urban (alte LISP-Hasen kennen den Namen) wenden, der in dieser Sache ebenfalls involviert war.
Aus dieser Geschichte kann ich allen LISP-Programmierern einige Empfehlungen ableiten:
1. Vermeidet LDATA wie die Pest! Sie sind absolut unnötig, die Daten können sehr viel eleganter in Dictionaries gespeichert werden.
2. Vermeidet es, Mitglied im "Autodesk Developer Network" (ADN) zu werden. Zwar kriegt man da fast kostenlos immer die aktuellen AutoCAD Versionen, aber man verkauft dafür seine Seele an Autodesk. Autodesk kann von den ADN Mitgliedern so ziemlich alles verlangen, z.B. auch, vermeintlich fehlerhafte Programme aus dem Verkehr zu ziehen. ADN-Mitglieder dürfen meines Wissens auch nicht für den LT-Extender programmieren.
3. Sucht Euch ein anderes Standbein neben der Programmierung von und für Autodesk Produkte. Autodesk ist ein multinationaler Konzern und verhält sich auch so. Eure persönlichen Interessen sind für Autodesk völlig irrelevant und stehen prinzipiell hinter dem Firmeninteresse zurück, selbst wenn Ihr auf rechtlich sicherem Boden steht. Einen Prozess gegen Autodesk oder mit meinem Kunden hätte ich mir alleine schon deshalb nicht leisten können, weil mich wegen des irre hohen Streitwerts schon ein einziger Brief eines Anwalts in den völligen Ruin getrieben hätte.
Tom Berger
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP