http://wiki.xscheme.de/index.php?p=sharpconnect

Eine kleine Analyse brachte das Problem zutage: der installierte Apache 2 Server fraß die Resourcen auf, anscheinend beim Versuch, sich mit der MySQL-Datenbank (die ich zwecks einfacher Weiterbetreibung dieses Blogs behalten habe) zu verbinden. Und egal, wo ich an der Konfiguration herumgeschraubt habe, es hat nichts gebracht.

Also bin ich einen anderen Weg gegangen: ein neuer Webserver musste her. Und hierbei fiel mein Auge auf nginx (Engine X). (Homepage) Eine kurze Installation und eine unglaublich einfach zu erledigende Konfiguration später, lief er dann auch schon. Und siehe da: keine Abstürze, keine langen Wartezeiten. Einfach Wow!

Jetzt muss ich nur noch cakePHP zum Laufen bekommen, dann wäre die Welt perfekt… Läuft.

Oh, noch nebenbei die Konfiguration für diesen Wordpress-Blog, falls jemand auf der Suche nach den Rewrite-Rules sein sollte (nginx unterstützt keine .htaccess Dateien):

server {
	listen 80;
	server_name dev.xscheme.de;

	location / {
		root [...];
		index index.php;
		if (!-e $request_filename) {
			rewrite ^ /index.php last;
		}
	}
	...
}

Wo genau ich das gefunden habe, weiß ich jetzt auch nicht mehr…

Da im Moment anscheinend wieder Änderungen am Last.FM-Webservice gemacht werden, die dazu geführt haben, dass LastSharp höchstens noch mithilfe der “Modifizierten Verbindung” (unter “Erweiterte Einstellungen” >> “Verschiedenes”) funktioniert, habe ich mir mal das Radio-API angesehen, das ja anscheinend die Zukunft des Radiostreamings bei Last.FM ist. Was mich daran allerdings stört, ist die umständliche Anmeldeprozedur: Token holen, Browser öffnen, auf Authentifizierung warten, Session holen.

Der Umweg über den Browser ist einfach unschön, weshalb ich nach einer Lösung gesucht habe, die den Login sowie die anschließende Bestätigung eines Users im Hintergrund simuliert, sodass er das eigentliche Programm nicht verlassen muss.

Funktionen, die Authentication-Token und -Session holen, werden im folgenden als gegeben betrachetet, z.B. durch LastFmLib.Net.

Wir brauchen nun also zwei Funktionen, die das Abschicken des Login-Formulars und das Klicken auf den “Zulassen”-Button vortäuschen. Beide Operationen produzieren eine HTTP-POST-Anfrage, funktionieren aber nur, wenn auch die richtigen Cookies vorhanden sind. (Das hat mich einige Zeit gekostet und dabei war die Lösung so einfach…) Es bietet sich an, die POST-Anfrage in eine Hilfsfunktion ExecutePOST zu packen, hier z.B. in C#:
(Namespace System.Net muss eingebunden sein)

// Löst das Cookie Problem: Immer denselben Container verwenden!
private static CookieContainer GlobalCookies = new CookieContainer();

// Sendet eine POST-Anfrage
public static void ExecutePOST(string uri, string data) {
    try
    {
        // Bereite die Anfrage vor
        HttpWebRequest request = (HttpWebRequest)WebRequest.Create(uri);
        request.Method = "POST";
        request.CookieContainer = GlobalCookies; // !!
        request.ContentType = "application/x-www-form-urlencoded";
        request.ContentLength = data.Length;

        // Schreiben der Daten
        ASCIIEncoding enc = new ASCIIEncoding();
        byte[] bdata = enc.GetBytes(bodyData);
        Stream str = req.GetRequestStream();
        str.Write(bdata, 0, bdata.Length);
        str.Close();

        // Schicke Anfrage ab und verwirf die Antwort
        HttpWebResponse response = (HttpWebResponse)request.GetResponse();
        response.Close();
    }
    catch { }
}

Will man überprüfen, ob die gewünschte Operation erfolgreich war, würde es sich vermutlich anbieten, die Antwort auszuwerten, aber darauf verzichte ich jetzt aus Zeitgründen.

Nächster Schritt ist die Untersuchung der Formulare auf der Last.FM-Seite, damit man weiß, welche Daten an welche Adresse gesendet werden müssen:

• Login: https://www.last.fm/login/
  • refererKey (leer)
  • backto (“/”)
  • username (Benutzername)
  • password (Passwort)
• Zulassen: http://www.last.fm/api/grantAccess
  • api_key (Last.FM schickt den sogar zweimal, wir deshalb sicherheitshalber auch…)
  • token (Authentication-Token)
  • referer (“/”)

Also, die beiden verbleibenden Funktionen in C#:

    // Lasse ein Programm zu
    public static void GrantAccess(string token)
    {
        ExecutePOST(
            "http://www.last.fm/api/grantAccess",
            "api_key=" + apiKey + "&api_key=" + apiKey + "&token=" + token + "&referer=/"
        );
    }

    // Melde den User bei Last.FM an
    public static void Login(string username, string password)
    {
        ExecutePOST(
            "https://www.last.fm/login/",
            "refererKey=&backto=/&username=" + Uri.EscapeDataString(username) +
            "&password=" + Uri.EscapeDataString(password)
        );
    }

Um jetzt eine gesamte Anmeldung zu simulieren, müsste man nun folgendes machen:

public static void Authenticate(string username, string password)
{
    string token = GetToken(); // irgendeine externe Funktion
    Login(username, password);
    GrantAccess(token);
    string session = GetSession(); // irgendeine externe Funktion
    // Mache etwas...
}

Das war’s auch schon. Wie gesagt fehlt hier ein Test, ob die Anmeldung erfolgreich war, aber irgendwie lässt sich das bestimmt einfach überprüfen. (Vllt. liefert Last.FM ja im Hintergrund einen HTTP-Error, der im Browser nicht auffällt?)

Jedenfalls, wenn jemand die Authentifizierung für das Last.FM-API 2.0 im Hintergrund ablaufen lassen will, ist das hier der Weg. Ich hoffe, es hilft.

Die Verwendung des Radio-APIs in LastSharp werde ich übrigens so lang wie möglich hinauszögern, da hier wieder einmal diverse Standards (HTTP, XML, …) unsachgemäß ausgelegt werden…

Das Problem, auf das ich hingewiesen wurde, als ich mich nach online verfügbaren Episoden von Flight of the Conchords erkundigt und die o.g. Seite als Quelle empfohlen bekommen habe, war, dass man, um an Downloadlinks zu kommen (ohnehin nicht das, was ich wollte), für jede Episode ein Captcha lösen und anschließend für jede einzelne Teil-Datei eine Serie von Klick-Copy-Paste ausführen musste. Und da kam mir die Idee, dass ganze in ein Programm zu packen: SerienjunkiesGML (Get My Links!)

Man gibt einfach die URL einer Serienjunkies-Seite in das dafür vorgesehene Textfeld ein (alternativ kann man auch direkt nach irgendetwas suchen), lässt das Programm die verfügbaren Episoden laden und startet mit einem Doppelklick auf die jeweilige Episode das Holen der Links.

Das Lösen des Captchas konnte ich nicht automatisieren (da sind schon viel größere Kaliber als ich dran gescheitert), aber die darauf folgenden Operationen, die zu den eigentlichen Links führen. D.h.: Hoster auswählen, Captcha lösen, warten, fertig!

Man kann auch gleich von vornherein mehrere Episoden auswählen und mit einem Klick auf “Go!” nacheinander abarbeiten.

Ein Hinweis noch: das Holen der Links funktioniert in einer Vielzahl der Fälle reibungslos, nur manchmal scheitert es. Dann muss man die entsprechenden URLs (die mit “download.serienjunkies.org”) beginnen, eben von Hand in den Browser eingeben.

Herausforderungen an mich waren: Untersuchung einer HTML-Seite, Simulieren einer POST-Request, Entwicklung einer intuitiven Benutzeroberfläche.

Download: http://dev.xscheme.de/wp-content/uploads/2009/07/serienjunkiesgml.exe

Aber alles, was mit Internet zu tun hat, kommt von anderen Herstellern: Firefox statt IE, Thunderbird statt Outlook,  ICQ statt dem Windows Live Messenger – und nicht zuletzt Google statt… Ja, statt was eigentlich?

So wird es womöglich vielen Usern gehen: man kennt nur Google. Ich suche ein Restaurant: Google. Ich will wissen, wie ich am besten zum TÜV komme: Google. Ich brauche Statistiken zu Google: Google. Die Ergebnisse sind nicht immer die besten (wenn auch meistens besser als sonstwo), aber diese sechs Buchstaben sind so unglaublich fest ins Bewusstsein der Internetnutzer gebrannt, dass jeder, der sich “daneben brennen” will, einen wirklich schweren Stand hat.

Und dann machte es Bing. Microsofts neue Suchmaschine – ich muss es zugeben – hat schon etwas für sich. (Böse Zungen behaupten, ihre anfängliche Popularität schulde sie v.a. der “Video”-Suche…)

Allein optisch gesehen: So sind beispielsweise die Hintergrundbilder der Startseite sehr gut gewählt und würden sich wohl durchaus für so manchen Desktop eignen. Nach Eingabe eines Suchbegriffs und Starten der Suche erhält man eine (Google-ähnliche) Ergebnisseite, deren einzelne Elemente nach Relevanz geordnet sind. Einen diesbezüglichen Vergleich mit Google kann ich zu diesem Zeitpunkt noch nicht machen, die Funktion Related Searches, die thematisch ähnliche Suchvorgänge vorschläft,  scheint mir dem Konkurrenten (endlich einmal, möchte man fast sagen!) einen Schritt voraus zu sein.

Eine weitere Innovation ist die Videosuche. Ohne Bing verlassen zu müssen, kann man sich Videos ansehen, sogar die Suchergebnisse selbst sind verkleinerte, vollständig abspielbare Clips! In den USA findet man über Bing sogar auf einfachste Weise ganze Episoden von z.B. “Dr. House” oder “Navy CIS”.

Bing Maps wiederum kommt mir schneller vor als sein Google-Pendant. Außerdem bietet es die Möglichkeit der Vogelperspektive (z.B. des Eiffelturms), was ich bei Google-Maps bisher auch noch nicht entdeckt habe.

Ich denke, ein paar Prozent Marktanteil kann Microsoft mit Bing wohl gewinnen, aber der große Angriff auf Google wird letztlich nicht stattfinden. Dafür lässt sich der Otto-Normal-User zu schwer von seinen Gewohnheiten abbringen. Mir gefällt es jedenfalls!

Als Beispiel sei die UVD von LastSharp gegeben, die wir im folgenden Codebeispiel mithilfe einer XSL-Transformation (DescriptionPage.xsl) in eine HTML-Datei verwandeln. Das soll illustrieren, wie einfach die Verwendung von UVD sein kann, wenn entsprechende Bibliotheken vorhanden sind:

UVD lastsharp = UVD.Create("http://dev.xscheme.de/uvd/lastsharp.uvd.xml");
lastsharp.Save("c:/lastsharp.htm", "http://dev.xscheme.de/uvd/DescriptionPage.xsl");

Nun haben wir eine Datei “lastsharp.htm”, die hier eingesehen werden kann und Beschreibungen in verschiedenen Sprachen und Längen bietet, Downloadlinks, etc… Außerdem sind (wie man bei der Ansicht des Quelltextes feststellen kann) auch die META-Tags zu Schlüsselwörtern und Beschreibungen bereits gesetzt, sodass die Seite auch für Suchmaschinen verwendbar ist.

Das UVD-Objekt (s. Code) bietet noch weitere Möglichkeiten, aber ich möchte nun auf den Update-Mechanismus zu sprechen kommen, den man mithilfe von UVD implementieren kann. Eine UVD kann einen Verweis auf die vorhergehende Version, sowie Informationen zum inkrementellen Update (lösche Datei X, aktualisiere Datei Y, …) enthalten, sodass man durch Untersuchen der Versionsgeschichte jede Version auf den neuesten Stand bringen kann.

Wir verwenden die folgenden (sinnlosen) Dateien zur Demonstration: Version 1.2 >> Version 1.1 >> Version 1.0. Mithilfe der UVDs läuft ein Update von Version 1.0 auf 1.2 folgendermaßen ab:

1. Extrahiere aus der UVD zu Version 1.2 die URL zu Version 1.1!
2. Speichere die Update-Informationen in der UVD zu Version 1.1!
3. Führe nacheinander die Update-Schritte (1.0 >> 1.1) und (1.1 >> 1.2) aus!

Die Bibliothek, an der ich gerade arbeite, verwendet hierfür sog. Update-Profile, die festlegen, welche Sprache und welches Betriebssystem für das Update berücksichtigt werden soll. Code:

UVD version12 = UVD.Create("http://dev.xscheme.de/uvd/updatetest1.xml");
UVDVersion currentVs = new UVDVersion(1, 0); // aktuelle Version
UpdateProfile profile = new UpdateProfile(); // OS und Sprache egal
Update u = profile.CreateUpdate(currentVs, version12);
foreach(UpdateSegment s in u)
{
    Console.WriteLine(s.ToString());
}
u.Execute("c:/program/"); // Programmverzeichnis muss angegeben werden!

Das liefert folgende Ausgabe:

[Add: file3.txt] http://www.download.de
[Execute: file3.txt]
[Remove: file4.txt]
[Add: file1.txt] http://www.download.de
[Update: file2.txt] http://www.download.de
[Execute: file3.txt]

Anschließend werden genau diese Schritte ausgeführt. Bei der Erstellung des Updates wird im übrigen mehr oder weniger intelligent vorgegangen: wenn eine Datei in Version 1.2 gelöscht wird, wird sie in Version 1.1 gar nicht erst hinzugefügt. Und warum eine Datei hinzufügen, wenn sie irgendwann später überschrieben wird? Dieses Verhalten lässt sich über das Update-Profil festlegen. Wenn deaktiviert, lautet die Ausgabe:

[Add: file4.txt] http://www.download.de
[Add: file2.txt] http://www.download.de
[Add: file3.txt] http://www.download.de
[Execute: file3.txt]
[Remove: file4.txt]
[Add: file1.txt] http://www.download.de
[Update: file2.txt] http://www.download.de
[Execute: file3.txt]

Soviel dazu. Was jetzt noch wichtig ist, ist die Übertragung der Bibliothek auf andere Programmiersprachen. Deswegen suche ich Entwickler, die mit mir gemeinsam UVD auf Java, PHP, etc… portieren. Bei Interesse einfach eine E-Mail schreiben an Yannick_Scherer@gmx.net! Aber man sollte sich bewusst sein, dass das einiges an Arbeit bedeutet.

Mehr habe ich vorerst nicht vorzuweisen… Außer vielleicht das ultimative “einzeilige” Update (mit einer sinnvollen Datei funktioniert es dann auch…):

new UpdateProfile()
       .CreateUpdate(new UVDVersion(1, 0), UVD.Create("http://dev.xscheme.de/uvd/updatetest1.xml"))
       .Execute("c:/program/");

Ein größeres Eingabefeld, die zuletzt gehörten Radiostationen – war das alles?

War es nicht, wie ein Klick auf das Play-Symbol zeigt. Denn nun wird zum einen das gewünschte gespielt, zum anderen läuft eine Diashow mit Bildern der Band / des Interpreten (überlagert von einem Anzeigetafel-Effekt) im Hintergrund ab, die durchaus Eindruck macht:

Und scrollt man ein wenig nach unten, sieht man eine lastgraph-ähnliche Grafik, die einem sagt, wann und wie oft man den entsprechenden Titel gespielt hat:

(lastgraph ist übrigens auch etwas, was sich jeder Last.FM-Nutzer, der seine musikalische Vergangenheit ergründen will, einmal ansehen sollte – aber das nur am Rande.)

Das kosmetische ist zwar ganz nett, aber davon hat man als User nicht unbedingt etwas. Das dachten sich wohl auch die Last.FM-Entwickler und haben noch eins draufgelegt: Multi-Tag- und Multi-Artist-Radios!

Ab sofort ist es möglich, im Player auf der Last.FM-Seite nach einem Klick auf einen der obigen Buttons bis zu drei Interpreten oder Tags einzutragen, die alle in die Zusammenstellung der Playlist miteinfließen. Das eröffnet einige neue Möglichkeiten, allerdings sollte man laut Last.HQ nicht darauf vertrauen, dass auch jede Kombination genug Daten für eine abspielbare Radiostation ergibt.

Mein erster Eindruck ist durchaus positiv: das Aussehen macht einiges her (der Nutzen wiederum ist bei den meisten optischen Neuerungen eher gering), und auch die Möglichkeit, mehrere Interpreten und Tags anzugeben, klingt vielversprechend. Soll heißen: ich werde jetzt erstmal Radio hören!

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.

- Stelle eine Verbindung zu einer Internetseite her, welche die Nummer der aktuellsten Version enthält.
- Vergleiche mit der eigenen Version.
- Zeige eine Benachrichtigung, falls die Server-Version neuer ist.

So macht das LastSharp mit der URL http://dev.xscheme.de/vls.htm. Nachteile: das Bearbeiten der Informationen, das von Hand (Textdatei erstellen, schreiben, FTP-Upload) geschehen muss, sowie die Notwendigkeit, entsprechenden Webspace zu besitzen.

Jetzt kam mir also eine (wirklich simple) Idee, wie man das vereinfachen und somit vielen Programmierern helfen könnte.

Man lagert das ganze auf eine eigene Website aus, auf der sich User anmelden können. Jeder Programmierer trägt seine Programme ein und deren aktuelle Version, Release Notes, das ChangeLog, die DownloadURL, etc… Anschließend werden diese Informationen über ein API zugänglich gemacht.

Jetzt fehlt nur noch die Implementierung der API-Funktionen für verschiedene Programmiersprachen und Plattformen, und voilà: Update-Benachrichtung ganz einfach. Für den Programmierer hat das nur Vorteile:

• eine weitere Website, auf der sein Programm erscheint,
• kein großer, zusätzlicher Programmieraufwand,
• zentrale, komfortable Verwaltung,
• keine Notwendigkeit, auf den FTP-Server zuzugreifen (bzw. dessen Zugangsdaten weiterzugeben),
• … (?)

War nur ein Gedankenspiel. Ich habe auch keine Ahnung, ob es sowas schon gibt. (Ich bezweifle es aber mal, weil meine Google-Suche zu dem Thema eher erfolglos war.) Im Moment bringe ich mir Ruby On Rails bei, was für so ein Projekt wohl eine ideale Grundlage wäre. Und vielleicht gibt es dann wirklich irgendwann einen “Update Notification Server”.

Soll ich?
Nein. Das steht da nicht ohne Grund.
Aber…
Kein Aber.
Was wohl passiert?
Schlimme Sachen. Schonmal von Tschernobyl gehört?
Ach, ein klein bisschen…
Denk nicht mal dran!!
Was soll’s.
AUTSCH!!!

Dieses Verhalten wurde nun in ein spielerisches Konzept überführt. Und zwar hier.

Und jetzt, genau hinhören, NICHT AUF DEN ROTEN KNOPF DRÜCKEN!

Ich gebe zu, das ist einer meiner weniger vernünftigen Beiträge. Aber zumindest hat es mir Spaß gemacht.