xscDevBlog – LastSharp & Co.

Das Problem der Updates

Ich bin in meinem vorletzten Artikel zum Thema Update-Check bereits darauf eingegangen: Versionsänderungen sind nicht immer leicht zu verfolgen und die Überprüfung auf Updates erfordert meist einen nicht zu unterschätzenden Programmier- und Verwaltungsaufwand. Weiterhin bedeutet es für den Entwickler selbst auch, dass er auf mehreren Hochzeiten tanzen muss: er stellt meist eine eigene Downloadseite bereit, die Links zu verschiedenen Versionen enthält, er aktualisiert gleichzeitig die Dateien, die für die Versionsüberprüfung zuständig sind, er kümmert sich um die Daten, die in irgendwelchen Softwareverzeichnissen (heise, chip.de, etc…) stehen, usw., usw… Als verantwortungsvoller Entwickler mit der Ambition, sein Programm unter die Leute zu bringen, hat man richtiggehend die Pflicht, diese Schritte durchzuführen – und das regelmäßig und mit äußerster Genauigkeit.

Hier nun also das (absolut logische und vernünftige) Konzept, das die meisten Beispiele, die man im Web zu dem Thema “Update-Check” findet, implementieren:

Augenscheinliche Probleme hierbei:

• Die Verwaltung der Programmdaten läuft (beim Otto-Normal-Programmierer) meist von Hand ab, d.h. man bearbeitet die Update-Datei (die nicht, wie im Beispiel, im XML-Format vorliegen kann), lädt sie von Hand auf den eigenen Webserver und ist aus Kompatibilitätsgründen meist an ein (demnach schwer erweiterbares) Format und an einen bestimmten Dateinamen gebunden.
• Je nachdem, wie detailliert die Update-Informationen sind (nur Versionsnummer vs. Versionsnummer, Änderungsdatum, Changelog, …), kann das Bearbeiten der Versionsdatei eine Heidenarbeit bedeuten.
• Der Entwickler muss das Programm erst einmal dazu bringen, einen funktionierenden Versions-Check durchzuführen.
• Und was passiert bei Programmen, die mehrsprachig funktionieren und beworben werden?

Die Idee im erwähnten Artikel war es also, den “Update Notification Server” nicht mehr als Eigentum des Entwicklers zu sehen, sondern als über ein API zugängliche Plattform im Internet, die Verwaltungsfunktionen komfortabel bereitstellt. Gleichzeitig wären verschiedene Bibliotheken für das API nötig, um dem Programmierer die Implementierung der Versionsprüfung fast gänzlich abzunehmen.

Was folgte, war ein Einspruch.

Es sei nicht garantierbar, dass der verantwortliche zentrale Server auch in zwei Jahren noch erreichbar sein würde, wurde argumentiert. Man könne das bei einem eigenen Server viel eher kontrollieren – und außerdem habe heutzutage ohnehin jeder Entwickler zumindest ein bisschen Webspace.

Dem kann man nicht widersprechen. Zwar würde eine zentrale Plattform den Komfort steigern, allerdings unvermeidbar auch das Risiko. Was also tun?

Unvereinbarkeit

Ein großes Problem bei den vielen Versionsprüfungsimplementierungen (was für ein Wort!) im Web ist die Unvereinbarkeit. Die meisten basieren auf verschiedenen Dateiformaten, die wiederum unterschiedlichen Informationsgehalt bieten. Eine reine Textdatei mit der Versionsnummer mag dem einen reichen, der andere benötigt aber vllt. auch schon den Downloadlink für die aktuelle Version dazu. Oder gar den Namen des Programms und Zusatzmeldungen. Kann passieren.

Wenn einem schließlich keine der Lösungen des World Wide Webs zusagt, dann bleibt nichts anderes zu tun, als eine bestehende Lösung anzupassen. Oder from scratch, also komplett neu zu beginnen. Das wiederum kostet Zeit und Energie, Schweiß und Kaffee, von den Nerven gar nicht erst zu sprechen. Was also tun? (Zweimal haben wir uns das jetzt schon gefragt!)

Eine Lösung, die es allen recht macht, wird es vermutlich nie geben, aber das heißt nicht, dass man nicht versuchen darf, in ihre Nähe zu kommen. Was benötigt wird, ist ein standardisiertes Dateiformat für Softwarebeschreibungen.

Standards

Es gibt so etwas bereits unter dem Namen Portable Application Description (PAD), nachzulesen beispielsweise in Wikipedia oder der Association of Shareware Professionals, anzusehen u.a. hier. Der Vorteil: das ist in der Tat ein Standard; der Nachteil: er wurde für den Vertrieb von Shareware entworfen. Außerdem wird ein alternatives XML-Namensraumkonzept verwendet, was sich für einen solchen Standard meiner Meinung nach nicht gehört.

Aber ganz allgemein hat das Format in meinen Augen signifikante Schwächen:

• Erweiterbarkeit: Man darf genau einen Screenshot angeben, eine Informations-URL, usw…
• Es findet keine Unterscheidung nach unterstützen Betriebsystemen statt. Angenommen, es gäbe einen Installer, der das Programm auf den neueren Windows-Versionen einrichtet, sowie einen, der es sogar auf Windows 95 zum Laufen bringt: PAD bietet keine Möglichkeit, diese Dateien zu unterscheiden bzw. überhaupt erst vernünftig gemeinsam anzubieten.
• Wir leben in einer multilingualen Welt. Die meisten Programme sind für mehrere Sprachen ausgelegt, doch würde man versuchen, Informations/Download-URLs nach Sprache anzubieten, würde man an PAD absolut insane werden.
• Überhaupt fehlt so etwas wie Hinweise auf Support im Web in PAD. Man kann Telefonnummern angeben, aber das Leben und die Lebenshilfe findet heutzutage nun einmal zu größeren Teilen im Internet statt als noch früher. Und E-Mail-Adressen bedeuten bloß Wartezeit.
• Man kann in PAD genau einen Entwickler angeben. Was macht man bei heutzutage weit verbreiteten Entwickler-Teams?
• Das Format hat eine Struktur, die das Verständnis manchmal erschwert. Aber es wird ja von Computern verarbeitet, also ist das akzeptabel. Andererseits: auch Suchmaschinencrawler sind Computerprogramme, und PAD (ein Standard!) wird von denen so gut wie ignoriert!
• Was Nutzer oftmals interessiert, ist die Entwicklung eines Programms: Was gibt es neues? Was wurde entfernt, was verbessert?

Es ist vielleicht etwas hochgegriffen, aber für die Softwarebeschreibung der heutigen Zeit muss ein neuer Standard erarbeitet werden. Und hier wird aus dem Gedankenspiel der Versuch.

Was macht Software aus?

Um welche Punkte müsste sich ein neues Format kümmern, was sind seine Prämissen und Ziele? Und was genau will ich eigentlich? Ein Brainstorming:

• Sprachenunterstützung
• Änderungsverfolgung
• Autorenliste
• Firmenkontaktdaten
• Lizenzinformationen
• Suchmaschinen-Metadaten
• Installationsanweisungen
• Abhängigkeiten: Was brauche ich, damit das Programm läuft?
• Einfacher Zugang zu Support-Quellen (Foren, Anleitungen, FAQ)

Es entwickelt sich vor meinem inneren Auge also langsam eine XML-Struktur, die das alles mit sich bringt: XML Application Description (XAD), veranschaulicht durch ein Beispiel (Rechtsklick >> Quelltext), das verwendete XSLT-Stylesheet und die DTD (das Dokument ist valide, ich weiß nicht, warum Firefox und der IE da rumspinnen).

Ein Gedanke

Dann kam mir ein Gedanke: nicht nur Programme unterliegen Änderungen, auch Dokumente, Filme, Serien lassen sich einem Versionskonzept unterordnen. Zwei Beispiele: die FAZ vom 30.04.2009 könnte ebensogut die Versionsnummer 2009.119 (der 30.04. ist der 119. Tag des Jahres 2009) tragen, und die Special Extended Edition von “Herr der Ringe: Die zwei Türme” könnte auch “Herr der Ringe 2.1″ heißen (wenn man keinen Wert auf Gewinn legen würde). Mit ein wenig Phantasie überträgt man das ganze auf Autos, CPUs, kurz gesagt: alles, was sich irgendwie als bildlicher Entwicklungsstrom darstellen lässt.

Wichtig hierbei ist die Möglichkeit, stets auf die früheren Versionen eines Objektes zugreifen zu können, weil im Idealfall Verweise auf diese vorhanden sind.

Wenn man also das oben erwähnte Format weiterentwickelt, verallgemeinert und anpasst, dann hat man ein mächtiges Werkzeug für weit mehr als bloß Software. Und hier wären wir.

Universal Version Description (UVD)

Da die Verwendung nicht mehr nur auf Programme beschränkt ist, ist es wichtig, anzugeben, was genau in einem Dokument beschrieben wird. Die Nomenklatur hierfür wäre idealerweise etwas wie “Kategories:Unterkategorie” oder “Kategorie” allein. Beispiele:

• media:tv-episode
• software:utility
• paper:specification
• paper:mathematics
• …

Folgendes wäre ein Beispiel für das kleinstmögliche UVD-Dokument:

<?xml version="1.0"?>
<!DOCTYPE uvd SYSTEM "http://dev.xscheme.de/uvd/uvd-1.dtd">
<uvd version="1.0.0" type="software:audio">
  <general>
    <name>WinAmp</name>
  </general>
</uvd>

Nicht sehr aussagekräftig, aber jetzt bauen wir noch Informations-Links (in verschiedenen Sprachen), sowie Beschreibungstexte (in verschiedenen Sprachen und Längen; die unterstützen Längenangaben sind 100, 255, 2000 und “any”) ein:

<?xml version="1.0"?>
<!DOCTYPE uvd SYSTEM "http://dev.xscheme.de/uvd/uvd-1.dtd">
<uvd version="1.0.0" type="software:audio">
  <general>
    <name>WinAmp</name>
    <urls>
      <url lang="en">http://www.winamp.com/</url>
      <url lang="de">http://de.winamp.com/</url>
    </urls>
    <descriptions>
      <description lang="en" maxlength="255">
        WinAmp is a multimedia player, supporting (...)
      </description>
      ...
    </descriptions>
  </general>
</uvd>

Deutsch und Englisch vorhanden, alles andere beliebig nachtragbar. Weitere Informationen wären: Lizenz, Keywords, Screenshots, etc…Anschließend könnte in einem neuen Abschnitt “release” die aktuelle Version (inkl. Downloadlinks nach Sprache und OS) beschrieben, in “contributors” alle Beteiligten aufgelistet und in “company” Informationen zum Firmenkontakt bereitgestellt werden.

Eine komplette Dokumentation des Formats würde den Rahmen aber noch mehr sprengen, deswegen wird hier auf die folgenden Dokumente verwiesen:

• “Spezifikation” zu UVD: http://dev.xscheme.de/uvd/Universal%20Version%20Description.txt
• DTD: http://dev.xscheme.de/uvd/uvd-1.dtd (Validate)
• Beispiele:
  • Programm-Release
  • Dokument
  • TV-Episode

Fazit

Meistens ist der eigene Blick von Selbstherrlichkeit getrübt, wenn man etwas in den eigenen Augen neues und tolles geschaffen hat. Deswegen brauche ich Meinungen hierzu.

Um das anfangs erwähnte Argument noch einmal aufzugreifen, man könne seinen eigenen Webspace besser kontrollieren, will ich hier erwähnen, dass ein UVD-Dokument natürlich überall liegen kann. Was bisher fehlt, sind Programme zur Verwaltung und Erstellung, sowie Bibliotheken zur Verarbeitung.

Vielleicht überschätze ich auch den Nutzen des ganzen. Kein Grund allerdings, den Stein nicht ins Rollen zu bringen.

Update (02.05.2009)

Ich will an dieser Stelle noch demonstrieren, wie sich das Format für einfache Versionsprüfung, sowie Update-Verarbeitung eignet.

Für einen normalen Versionscheck würde schon so etwas reichen:

<uvd version="1.0.0" type="software:ripper">
  <general>
    <name>LastSharp</name>
  </general>
  <release>
    <date>
      <day>20</day>
      <month>4</month>
      <year>2009</year>
    </date>
    <version>
      <major>0</major>
      <minor>4</minor>
      <build>1</build>
    </version>
  </release>
</uvd>

Und folgende Datei könnte von einem Updater automatisch verarbeitet werden:

<uvd version="1.0.0" type="software:ripper">
  <general>
    <name>LastSharp</name>
  </general>
  <release>
    <date>
      <day>20</day>
      <month>4</month>
      <year>2009</year>
    </date>
    <version>
      <major>0</major>
      <minor>4</minor>
      <build>1</build>
    </version>
    <files>
      <file name="LastUtility" os="any" type="lib" filename="LastUtility.dll"
            update-action="update" update-path=".inc" direct-download="no">
        <urls>
          <url lang="all">http://download.server.tld/LastUtility.dll</url>
        </urls>
      </file>
      <file name="LastSharpExe" os="any" type="exe" filename="LastSharp.exe"
            update-action="update" direct-download="no">
        <urls>
          <url lang="all">http://download.server.tld/LastSharp.exe</url>
        </urls>
      </file>
      <file name="SettingsFile" os="any" type="xml" filename="settings.xml"
            update-action="remove" />
      <file name="LastSharpFull" os="any" type="package" filename="LastSharp041.zip"
            update-action="ignore">
        <urls>
          <url lang="all">http://download.server.tld/LastSharp041.zip</url>
        </urls>
        <descriptions>
          <description lang="de" maxlength="any">
            Das vollständige Paket mit allen Dateien von LastSharp 0.4.1.
          </description>
        </descriptions>
      </file>
    </files>
  </release>
</uvd>

Wenn man genau hinsieht, erkennt man die Anweisungen an den Updater:

1. Lade die Datei “LastUtility.dll” von der angegebenen URL herunter und überschreibe ihre Entsprechung im Unterverzeichnis “.inc”.
2. Tue dasselbe mit der Datei “LastSharp.exe”, allerdings diesmal im Hauptverzeichnis. (“update-path” fehlt)
3. Lösche die Datei “settings.xml” im Hauptverzeichnis.

Der letzte “file”-Eintrag enthält das Gesamtpaket, das beim automatischen Update ignoriert wird. (“update-action=’ignore’”) Gleichzeitig wird es aber dem User im Gegensatz zu den Dateien zuvor direkt zugänglich gemacht. (“direct-download=’no’” soll verhindern, dass evtl. Clients die so markierten Links dem User zeigen)

Wenn man jetzt bedenkt, dass ein wichtiger Punkt von UVD die Verlinkung mit den früheren Versionen ist (Der “release”-Tag bietet das Attribut “previous”, das auf das entsprechende UVD-Dokument verlinkt!), sieht man schnell, dass man mit diesem Format jede beliebige Version aktualisieren kann, wenn man sich in der Versionsgeschichte “zurückhangelt”.

Ich hoffe, diese kleine Demonstration hat noch einmal verdeutlicht, worin ich u.a. den Nutzen des Formats sehe.