Download: http://files.xscheme.de/LastSharp/LastSharp0.4.5-incarnation2.zip

Der Zusatz “Incarnation 2″ rührt von der Tatsache her, dass ich aktuell an einer komplett neuen Version arbeite, die mit dieser nicht mehr viel gemein hat. Und da es auch zuvor schonmal so einen Neuanfang gegeben hat, ist die passende Zahl eben die “2″.

Scrobbling sollte nun auch wieder funktionieren, außerdem gibt es eine Möglichkeit, sich nun auch bei noch nicht endgültigen Releases über Updates informieren zu lassen (unter “Erweiterte Einstellungen” das Häckchen bei “Nur stabile Versionen melden” entfernen).

http://devboard.xscheme.de/read.php?1,706

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

Es stellt sich zuerst die Frage: Was wollen wir? Ich für meinen Teil würde z.B. gerne wissen, wo und wann Kasabian demnächst Konzerte geben (Nicht, dass die Chance bestünde, das München auf der Liste wäre, aber dennoch…), und somit böte sich der API-Aufruf artist.getEvents zur näheren Betrachtung an: Welche Parameter hat er, wie muss er ausgeführt werden und wie sieht die Antwort aus?

Wir sehen, dass es zwei Parameter gibt (“artist” und “api_key”, beide benötigt) und dass die Antwort ein XML-Dokument ist, dass die Wurzel “lfm” hat, anschließend den Knoten “events” und viele Kindknoten “event”, die die einzelnen Konzerte enthalten. Diese wiederum besitzen Werte für die auftretenden Künstler, den Ort, die Zeit, Ticketverkäufe, etc… Das Beispiel von der API-Seite:

<events artist="Cher" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" total="4">
<event>
    <id>599858</id>
  <title>Cher</title>
  <artists>
    <artist>Cher</artist>
    <headliner>Cher</headliner>
  </artists>
  <venue>
    <name>The Colosseum at Caesars Palace</name>
    <location>
      <city>Las Vegas</city>
      <country>United States</country>
      <street></street>
      <postalcode></postalcode>
      <geo:point>
         <geo:lat>36.2265501474709</geo:lat>
         <geo:long>-115.0048828125</geo:long>
      </geo:point>
      <timezone>PST</timezone>
     </location>
    <url>http://www.last.fm/venue/8841108</url>
  </venue>
  <startDate>Sat, 16 Aug 2008</startDate>
  <startTime>19:30</startTime>
  <description></description>
  <image size="small">...</image>
  <image size="medium">...</image>
  <image size="large">...</image>
  <attendance>42</attendance>
  <reviews>0</reviews>
  <tag>lastfm:event=669027</tag>
  <url>http://www.last.fm/event/599858</url>
  <website>http://...</website>
  <tickets>
    <ticket supplier="...">http://...</ticket>
    ...
  </tickets>
</event>
...
</events>

SharpConnect stellt die folgenden Klassen zur Verfügung:

• SharpConnect.Apitizer.Apitizer bzw. SharpConnect.Xml.XmlApitizer zur Verwaltung von Methoden
• SharpConnect.Apitizer.Method zur Darstellung von Methoden
• SharpConnect.Apitizer.Parameters zur Darstellung von Parametern
• SharpConnect.Apitizer.Accessor als Zugriffsklasse für Antworten
• SharpConnect.Apitizer.Rule bzw. SharpConnect.Xml.XmlRule zur Darstellung von Accessor-Regeln
• SharpConnect.Apitizer.Codec bzw. SharpConnect.Xml.XmlCodec zur Umwandlung von Anfragen und Antworten.

Mehr brauchen wir eigentlich nicht, und auch, wenn das keine wirklich kurze Liste ist, die Verwendung der einzelnen Klassen ist nicht besonders kritisch. Beginnen wir mit dem schwersten, dem Codec.

Wenn wir diesen auf Basis von XmlCodec aufbauen, haben wir die Hälfte schon geschafft:  die Antworten (Response) werden automatisch in einen Accessor für XML umgewandelt und können anschließend anhand der Regeln, die wir noch definieren werden, durchlaufen werden. Was wir noch machen müssen, ist, die Daten, die gesendet werden sollen (Request), vorzubereiten. LastFM erwartet die einzelnen Parameter als Query-String von Name-Wert-Paaren, also z.B.:

method=artist.getEvents&artist=Cher&api_key=b25b959554ed76058ac220b7b2e0a026

Der API-Key wird immer angehängt, bei Anfragen, die Daten verändern, sogar noch eine Session und ein API-Secret, diese lassen wir jedoch hier unter den Tisch fallen. Man muss es ja nicht gleich übertreiben. Unser Last.FM Codec könnte also folgendermaßen aussehen:

 public class LastFMCodec : XmlCodec
 {
   private string apiKey;

   public LastFMCodec(string key)
     : base("lfm", null)
   {
     this.apiKey = key;
   }

   public override Request Encode(Method m, Parameters p)
   {
     string method = m.Name;
     string query = "method=" + method + "&";
     query += p.QueryString("&", "=");
     query += "api_key=" + this.apiKey + "&";
     if (m.IsPOST) return new Request("", query);
     else return new Request(query, "");
   }
 }

Das wars auch schon. Das meiste wird ohnehin von SharpConnect erledigt, sodass wir uns nun auf den Apitizer konzentrieren können. Auch hier ist die Klasse XmlApitizer eine wunderbare Grundlage, die nicht viele Ergänzungen benötigt:

 public class LastFMApitizer : XmlApitizer
 {
   public LastFMApitizer(string key, WebProxy p)
     : base("http://ws.audioscrobbler.com/2.0/", new LastFMCodec(key), p)
   {
      AddMethods(this);
   }

   private static void AddMethods(XmlApitizer api) {
     // Methods here!
   }
 }

Wir haben nun also einen Apitizer erstellt, der alle Anfragen an “http://ws.audioscrobbler.com/2.0/” sendet und den soeben definierten Codec verwendet. Nun müssen wir dem Apitizer nur noch sagen, was er eigentlich kann.

Eine Methode wird definiert durch

• einen Namen,
• eine Liste von Parameter-Namen,
• eine Liste von boolschen Werten, die angibt, welche Parameter benötigt werden, sowie
• einen Wert der angibt, ob die Anfrage über HTTP-POST läuft oder nicht.

In unserem Fall sieht dies nun folgendermaßen aus (Der API-Key wird im Encoder automatisch hinzugefügt!):

 Method artistGetEvents = new Method(
   "artist.getEvents",
   new String[] { "artist" },
   new bool[] { true },
   false
 );

Was machen wir nun mit der Antwort dieses Aufrufs? Die Antwort: wir verwenden die Klasse XmlRule, um Zuordnungen zwischen Attributnamen und Knoten des Antwortdokuments herzustellen. Das Mittel der Wahl ist hierbei XPath.

 XmlRule Image = new XmlRule();
 Image.Set("URL", "self::node()");
 Image.Set("Size", "@size");

 XmlRule Event = new XmlRule();
 Event.Set("Name", "title");
 Event.Set("ID", "id");
 Event.Set("Artists", "artists/artist");
 Event.Set("Headliner", "artists/headliner");
 Event.Set("Date", "startDate");
 Event.Set("Time", "startTime");
 Event.Set("Description", "description");
 Event.Set("Images", "image", Image);             // !!!
 Event.Set("Attendance", "attendance");
 Event.Set("ReviewCount", "reviews");
 Event.Set("UniqueTag", "tag");
 Event.Set("Website", "website");

 XmlRule rule = new XmlRule();
 rule.Set("Count", "/lfm/events/@total");
 rule.Set("Events", "/lfm/events/event", Event); // !!!

Zuerst wird eine Bild-Regel definiert: das Attribut “URL” liefert den Wert des Knotens, “Size” den Wert des “size”-Attributs. Die beiden blauen Zeilen zeigen die Verwendung von bestehenden Regeln als Unterobjekte: die Regel “Image” ist auf alle Knoten anwendbar, die über das Attribut “Images” gefunden werden, d.h. jeder Knoten aus “Images” erlaubt wieder Zugriff auf “URL” und “Size”. Gleiches für “Events”: alle Knoten, die über den XPath-Ausdruck “/lfm/events/event” gefunden werden, haben Attribute “Name”, “ID”, “Artists”, …

Wir müssen nur noch dem Decoder sagen, dass er diese Regel verwenden soll, wenn er eine Antwort auf eine “artist.getEvents”-Anfrage erhält. Dies geschieht durch gleichzeitiges Registrieren der Methode im Apitizer und Codec mittels “Apitizer.Method” (Wir befinden uns wieder in der statischen Funktion “AddMethods” von oben):

api.Method(artistGetEvents, rule);

Und nun sind wir fertig.

Beispiel gefällig?

Das folgende Beispiel funktioniert mit meiner aktuellen Implementierung von SharpConnect. Neu im Vergleich zum eben besprochenen ist nur die Klasse “LastFMValue”, die den Accessor für XML-Dokumente darstellt:

 LastFMApitizer lfm = new LastFMApitizer("b25b959554ed76058ac220b7b2e0a026", "", null);

 LastFMValue resp = lfm.Execute("artist.getEvents", new Parameters(
   "artist", "Kasabian"
 ));
 if (resp != null)
 {
   Console.Write(resp.ToString()); // oder z.B. Console.Write(resp.All("Events")[2].Value("Date"));
 }
 Console.ReadLine();

Die Ausgabe sieht so oder  ähnlich aus (auf all diese Attribute und Array-Elemente könnte man mittels “resp.Get(attribut)”  und “resp.All(attribut)” zugreifen, vgl. den Concept-Artikel):

  Status : ok
  Count : 14
  Events[0] :
    Status : ok
    Name : Kasabian
    ID : 1408186
    URL : http://www.last.fm/event/1408186+Kasabian+at+Tivoli+Oudegracht+on+27+May+2010
    Artists : Kasabian
    Headliner : Kasabian
    Date : Thu, 27 May 2010 12:08:01
    Description : ...
    Images[0] :
      URL : http://userserve-ak.last.fm/serve/34/284053.jpg
      Size : small
    Images[1] :
      URL : http://userserve-ak.last.fm/serve/64/284053.jpg
      Size : medium
    Images[2] :
      URL : http://userserve-ak.last.fm/serve/126/284053.jpg
      Size : large
    Images[3] :
      URL : http://userserve-ak.last.fm/serve/252/284053.jpg
      Size : extralarge
    Attendance : 87
    ReviewCount : 0
    UniqueTag : lastfm:event=1408186
    Website : http://www.tivoli.nl/agenda/informatie/datum/do-27-mei-2010/titel/KASABIAN
  Events[1] :
    Status : ok
    Name : Pinkpop 2010
    ID : 932823
    URL : http://www.last.fm/event/932823+Pinkpop+2010
    Artists[0] : Green Day
    Artists[1] : Pixies
    Artists[2] : Kasabian
    Artists[3] : The Prodigy
    Artists[4] : Rammstein
    Artists[5] : John Mayer
    Artists[6] : Editors
    Artists[7] : Mika
    Artists[8] : Wolfmother
    Artists[9] : Kate Nash
    Artists[10] : Mando Diao
    Artists[11] : Paolo Nutini
    Artists[12] : P!nk
    Artists[13] : Florence + The Machine
    Artists[14] : Skunk Anansie
    Artists[15] : Gogol Bordello
    Artists[16] : Biffy Clyro
    Artists[17] : Yeasayer
    Artists[18] : The Temper Trap
    Artists[19] : Danko Jones
    Artists[20] : Gossip
    Artists[21] : 2 Many DJ's
    Artists[22] : Moke
    Artists[23] : Kitty, Daisy & Lewis
    Artists[24] : Caro Emerald
    Artists[25] : Triggerfinger
    Artists[26] : Destine
    Artists[27] : DeWolff
    Artists[28] : Sungrazer
    Headliner : Green Day
    Date : Fri, 28 May 2010 21:24:01
    Description : ...
    Images[0] :
      URL : http://userserve-ak.last.fm/serve/34/42600061.jpg
      Size : small
    Images[1] :
      URL : http://userserve-ak.last.fm/serve/64/42600061.jpg
      Size : medium
    Images[2] :
      URL : http://userserve-ak.last.fm/serve/126/42600061.jpg
      Size : large
    Images[3] :
      URL : http://userserve-ak.last.fm/serve/252/42600061.jpg
      Size : extralarge
    Attendance : 560
    ReviewCount : 1
    UniqueTag : lastfm:event=932823
    Website : http://www.pinkpop.nl
  Events[2] :
    Status : ok
    Name : Kasabian
  ...

Ich arbeite im Moment an einer vollständigen Abbildung des Last.FM-APIs, auch wenn ich nicht weiß, ob ich das nicht lieber jedem selbst überlassen sollte. In den Worten von Morpheus:

I can only show you the door, you have to walk through it!

Mein Problem begann beim Last.FM-Webservice: wie kann ich dessen Funktion möglichst einfach zugänglich machen, ohne Flexibilität zu verlieren? Ich wollte nicht auf eine bereits bestehende Lösung zurückgreifen, da dort womöglich viel mehr angeboten als letztendlich benötigt wird; genauso sollte keine neue, nur für Last.FM nutzbare Implementierung geschaffen werden, sei sie auch noch so einfach zu verwenden – irgendwann müsste dann doch wieder von vorne begonnen werden… Eine neue Abstraktionsschicht musste her, eine vereinfachte, für den Otto-Normal-Programmierer sinnvolle Minimal-Version von WSDL quasi. Etwas, das leicht zu erlernen und zu verwenden ist, ohne unnötigen Ballast.

Methoden

Im Prinzip kann man jede Funktion eines WebServices als Methode beschreiben. Diese hat:

• einen Namen,
• eine Reihe von Parametern,
• Informationen zu diesen Parametern (Typ? Optionaler Parameter?),
• sowie ein Zugriffsprotokoll
• und ein Antwortformat.

Je genauer man Methoden beschreibt, desto sicherer kann man sich sein, dass ein Aufruf, der alle Anforderungen erfüllt, auch wirklich erfolgreich ist. Nur: die Daten, die so fällig werden, nehmen schnell an Größe und Komplexität zu, sodass man eigentlich nicht umhin kann, das Messer anzusetzen und so viel wie möglich wegzuschneiden:

• Zugriffsprotokoll:
  So ziemlich alle wichtigen WebServices sind über HTTP ansprechbar. Es ist nicht verwerflich, sich hierauf zu begrenzen.
• Parametertypen:
  Letztlich erfolgt an irgendeiner Stelle immer eine Umwandlung in Strings, vor allem bei textbasierten Protokollen wie HTTP. Ersparen wir uns also die statische Typisierung, die ohnehin schwer zu implementieren ist.
• Antwortformat:
  Auch hier könnte man sagen, dass man an XML ohnehin nicht vorbeikommt, allerdings ist in diesem Bereich Flexibilität wichtig: neue Formate wie JSON sind auf dem Vormarsch, vor allem für einfachere Anwendungen. Einigen wir uns darauf: Die Methode muss nicht wissen, wie ihre Antwort aussieht!

Übrig bleibt das in folgender Schreibweise zusammengefasste bisschen Information:

Methode   M  = (Name, HTTP-Methode, [Parameter P1, Parameter P2, ...])
Parameter Px = (Name, required?)

Als Beispiel sei der Aufruf artist.getInfo des Last.FM-APIs notiert:

Methode M1   = (artist.getInfo, GET, (artist, false), (mbid, false), (username, false), (lang, false))

Diese Methode ist bewusst gewählt: die Spezifikation besagt, dass sie entweder mit einem Künstlernamen (artist) oder einer Musicbrainz-ID aufgerufen werden kann. Dies haben wir hier nicht abgebildet, können wir aber gut und gerne dem Nutzer überlassen oder eben nachholen, indem wir zwei verschiedene Methoden definieren:

Methode M1   = (artist.getInfo, GET, (artist, true), (username, false), (lang, false))
Methode M2   = (artist.getInfo, GET, (mbid, true), (username, false), (lang, false))

Wir können jede Operation, die ein WebService bietet, so aufschreiben – und viel wichtiger: wir können dies in jeder objektorientierten Sprache sehr einfach implementieren. Ein paar Konventionen zur Schreibweise sind jedoch noch nötig:

• Methodenaufruf:

  Aufruf A = M(P1 -> V1, P2 -> V2, ...)

  Der Parameter P1 wird mit V1 belegt, usw… z.B. für artist.getInfo (s.o.):

  Aufruf A1 = M1(artist -> Kasabian, username -> xschemer, lang -> de)

  Die Reihenfolge der Parameter ist unerheblich.

• Methodenaufruf ohne Parameterzuordnung:

  Aufruf A = M(V1, V2, V3, ...)

  V entspricht dem ersten in der Definition angegebenen Parameter, usw… Semantisch identisch zum obigen Beispiel:

  Aufruf M1(Kasabian, xschemer, de)

Die Definition eines APIs haben wir erledigt, den Methodenaufruf spezifiziert. Aber was machen wir nun damit?

Request, Response & Codec

Ein WebService kann mit einer Methode erst etwas anfangen, wenn sie in dem Format aufgerufen wird, dass er versteht. Für Last.FM muss z.B. immer ein “method”-Parameter übergeben werden, der den Namen enthält, zusätzlich noch der API-Key, evtl. eine Session und eine Signatur.

Damit wir einen Aufruf in das richtige Format bringen können, brauchen wir einen sog. Codec, also einen Umwandler. Er nimmt einen Methodenaufruf und produziert daraus die URL, an die eine Anfrage geschickt wird, sowie die Daten, die gesendet werden. Ebenso verarbeitet er die Antwort des Servers zu einem standardisierten Objekt (Accessor), das weiter unten beschrieben ist. Im Prinzip handelt es sich also nur um zwei separate Funktionen, konkretisiert:

Request  Rq = (URL, Daten)
Response Rp = (Request, Daten)
Codec    C  = (Encoder, Decoder)
Encoder  E  = Funktion: Aufruf -> Request
Decoder  D  = Funktion: Response -> Accessor

Wenn wir hier aufhören, haben wir folgenden Datenfluss:

User -> Codec -> Encoder -> WebService -> Decoder -> Codec -> User

Was uns immer noch fehlt ist eine Überprüfung, ob zumindest alle benötigten Parameter vorhanden sind. Zwar könnte man diese in den Encoder packen, doch das sollte nicht dessen Aufgabe sein, schließlich müsste er dafür alle Methoden kennen, was schlicht und einfach keinen Sinn macht.

Apitizer – Wächter der Methoden

Diese Verwaltung wird also in ein neues Objekt verlagert, den Apitizer. Er übernimmt die folgenden Aufgaben:

• Speicherung aller verfügbaren Methoden,
• Verwaltung genau eines Codecs,
• Auswahl der passenden Methode zu einem Name-Parameterliste-Paar,
• sowie Überprüfung von Parameterlisten auf Vollständigkeit.

Jede Kommunikation eines Users mit dem API sollte über den Apitizer laufen, nicht direkt über Encoder und Decoder! Das folgende Bild soll das nochmals verdeutlichen:

Was man hier auch sieht, ist die Möglichkeit, des Encoders/Decoders auf externe Daten zurückzugreifen, z.B. den API-Key bei Last.FM. Aber nun erstmal zum wohl wichtigsten Teil dieses Konzepts, den Accessor.

Accessor

Wenn wir eine Antwort bekommen, interessieren uns bestimmte Teile davon. Allerdings existieren unterschiedliche Formate, unterschiedliche Strukturen. Es gilt also, diese auf ein einfaches Konzept zurückzuführen.

Betrachten wir die grundsätzlichen Arten von Daten, die es gibt:

• einzelne Werte,
• Mengen von Werten,
• Zusammengesetzte Strukturen,
• sowie Mengen von zusammengesetzten Strukturen.

Definieren wir diese folgendermaßen:

Wert    V  = String | List | Struct
List    L  = (Wert, Wert, ...)
Struct  S  = (Mapping, Mapping, ...)
Mapping Mp = String -> Wert

In Worten: ein Wert ist entweder ein String, eine Liste oder eine Struktur; eine Liste ist eine Menge von Werten und eine Struktur ist eine Menge von Zuordnungen von Strings zu Werten. Letzteres entspricht den Attributen eines Objekts. (z.B. kann die Struktur “Rechteck” eine Zuordnung “Höhe” -> “10″ besitzen)

Ein Accessor bildet nun beliebige Daten mithilfe von Regeln auf die eben besprochenen Einheiten ab:

Regel          Rl = (AccessMapping1, AccessMapping2, ...)
AccessMapping  AM = (Attributname, Transformation, Regel)
Transformation T  = Funktion: Daten -> Daten[]
Accessor       Ac = (Daten, Regel)

Der Accessor muss in der Lage sein, die folgenden Operationen auszuführen:

• das passende Mapping zu einem Attributnamen finden,
• den aktuellen Daten-Wert als String ausgeben,
• einen Accessor erstellen, der einem Attribut entspricht,
• eine Menge von Accessors erstellen, die einer Menge von Attribut-Werten entspricht.

Und wieder wird definiert (das ist keine besondere Beschreibungssprache, nur Pseudo-Code):

Accessor.map(attribut)  -> AccessMapping
Accessor.value()        -> (String) Accessor.Daten
Accessor.get(attribut)  -> Accessor.all().firstElement
Accessor.all(attribut)  ->
    m = Accessor.map(attribut);
    d = m.Transformation(Accessor.Daten);
    Array for all d[n]: new Accessor(d[n], m.Regel)

Es wird Zeit für ein Beispiel. Und da XML mein Hauptanliegen ist, sollte ich es wohl auch verwenden.

Beispiel: XML Accessor

Auf XML-Daten kann mithilfe von XPath zugegriffen werden und dies kann man wunderbar nutzen. Nehmen wir das folgende Dokument:

<fruitbasket>
  <count>2</count>
  <fruit>
    <name>Apple</name>
    <color>red</color>
  </fruit>
  <fruit>
    <name>Orange</name>
    <color>orange</color>
  </fruit>
</fruitbasket>

Wir können nun Regeln definieren, wobei wir davon ausgehen, dass Transformationen eindeutig durch einen XPath-Ausdruck bestimmt sind und auf dem Wurzelknoten des übergebenen Dokuments arbeiten, z.B. lässt sich auf die Anzahl der Früchte ausgehend vom Wurzelnoten “fruitbasket” mittels “count” zugreifen:

Regel Fruitbasket = (
  ("Count", xpath: "count", None),
  ("Fruits", xpath: "fruit", Fruit)
)

Regel Fruit = (
  ("Name", xpath: "name", None),
  ("Color", xpath: "color", None)
)

Diese Regeln müssen irgendwo im Decoder definiert sein, ebenso eine Zuordnung Methodenname -> Regel, damit der Decoder weiß, für welche Methode er welche Regel verwenden soll. Ein Accessor, der das oben beschriebene Dokument (abgekürzt als FRUITDOC) repräsentiert wäre also:

Accessor MyBasket = (FRUITDOC, Fruitbasket)

Wenn man nun die Methode “all” für das Attribut “Fruits” aufruft, wird der Accessor feststellen, dass dies dem AccessMapping (“Fruits”, xpath: “fruit”, Fruit) entspricht. Er wendet also die Transformation auf das Dokument an (findet also alle Knoten, die dem XPath-Ausdruck “fruit” entsprechen) und erstellt mithilfe der gegebenen Regel Fruit neue Accessors. Das Ergebnis wäre also:

MyBasket.all("Fruits") = [
  Accessor("<fruit><name>Apple</name>...", Fruit),
  Accessor("<fruit><name>Orange</name>...", Fruit)
]

Führen wir nun “get” für das Attribut “Color” des ersten Ergebnisses (nennen wir es E1) aus, erhalten wir das AccessMapping (“Color”, xpath: “color”, None). Eine Auswertung des XPath-Ausdrucks liefert hier genau einen Knoten, aus dem der neue Accessor V1 erstellt wird:

V1 = E1.get("Color") = Accessor("<color>red</color>", None)

Und hier können wir den Wert auslesen:

V1.value() = "red"

Das gleiche Ergebnis würde übrigens der folgende Ausdruck liefern:

MyBasket.get("Fruits").get("Color").value()

Soviel zu Accessors.

Warum? Warum? Warum?!

Wie anfangs (und das ist lange her) erwähnt, arbeite ich an meiner Version des Last.FM-APIs auf Basis dieses Konzepts. Dieses wiederum wird die Basis für neue Versionen von LastSharp und LeSharp sein, wobei ich v.a. für ersteres Programm grundlegende Änderungen angedacht habe. (Multiuser-Support mit mehreren Downloads, Anhören und Downloaden gleichzeitig, …)

Es hat also schon alles seinen Sinn. Danke fürs Zuhören.

Attributname : String, Transformation, Unterregel

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…

Aber jetzt sollte wieder alles funktionieren. Wenn nicht, bitte bescheid sagen!

Update: Um das Forum kümmere ich mich morgen.

Download:
https://sourceforge.net/projects/lastsharp/files/lesharp/LeSharp%201.2.2/LeSharp1.2.2.zip/download

Zum einen bin ich letzten Samstag umgezogen (der klassische Studentenweg: von Zuhause weg und in eine 2er-WG) und da jetzt dann doch ziemlich eingebunden. Ich hab noch nichtmal ein Bett… (Lieferzeit: 3 Wochen)

Seit September arbeite ich zudem als Werkstudent bei Telefonica O₂ Germany. Die 20h-Woche ist jetzt vielleicht nicht sooo auslastend, aber es summiert sich dann doch.

Zuguterletzt geht dann demnächst auch die Uni wieder los, was mein Pensum dann auf 50h die Woche erhöht. Aber mei, wir sind jung – wenn wir jetzt sowas nicht packen, wann dann?

Jedenfalls werde ich alle offenen Kommentare beantworten, sobald ich Zeit habe. Ebenso wird es dann neue Versionen der einzelnen Programme geben. Danke für’s Verständnis!

Und heute war ich dann soweit, dass ich eine gar nicht so üble Version vor mir hatte, die ich nun (nicht detailliert, eher angeberischerweise ) präsentieren will. Vorhang auf für Scripe!

(Der Name hat mehrere Hintergründe: zum einen wäre da der Schreibfehler, der schonmal beim Wort “Scripte” auftaucht, zum anderen findet sich ein Ursprung im englischen “to scribe”, was soviel wie “vorzeichnen” bedeutet. Zuguterletzt sagt einem das allwissende Urban Dictionary, das “scripe” das Äquivalent von “a load of rubbish”, also etwas nicht ganz hochwertigem ist. Das ist auch in Ordnung so: Scripe ist der Weg, den ich einschlagen würde, wenn ich eine Scriptsprache zu entwickeln hätte. Zwar sind Grundkonzepte, die sich auch im professionelleren Einsatz finden, vorhanden, aber Scripe erhebt in dieser Hinsicht keinerlei Anspruch auf Vollständigkeit oder übermäßige Effizienz. “Quick and Dirty” wäre dennoch übertrieben, dann doch eher “Quick and Not-So-Clean“…)

Die Suppe im Titel lässt das Prinzip erahnen: Suppen brauchen Gewürze, um zu schmecken, und hierbei ist es wichtig auf die Mischung zu achten. Ebenso wird jeder seine Suppe anders würzen, je nach Vorlieben oder Vorhaben. Eine Scriptsprache ist da nicht anders: hier eine Prise Variablenverwaltung, dort ein Löffel Arithmetik. Voilà.

Dieses Suppenprinzip findet man heutzutage überall, hauptsächlich in der Unix/Linux-Welt, wo man je nach Bedarf auf einfachste Art und Weise ein Paket nachladen kann und das Gesamtsystem somit bis ins letzte Eck modifizierbar bleibt. Auch Scripe verwendet solche Pakete, allerdings eben für die Features der Programmiersprache!

Folgender C#-Code erzeugt einen Prozessor, der den Shunting-Yard-Algorithmus verwendet, um die Eingabe zu parsen. Anschließend erhält er vier Pakete: eines für arithmetische Operationen, eines für String-Operationen, eines für Ein- und Ausgabe, und eines für Variablendefinition und -verwaltung. Anschließend wird eine Eingabe-Auswertungs-Schleife gestartet.

// Create processor
Processor p = new Processor(
    new ShuntingYardAlgorithm()
);

// Add packages
p.AddPackage(new Scripe.Evaluators.Arithmetic.ArithmeticPackage(true));
p.AddPackage(new Scripe.Evaluators.Strings.StringPackage("&", "$"));
p.AddPackage(new Lapicon.Evaluators.InputOutput.InputOutputPackage());
p.AddPackage(new Lapicon.Evaluators.Variables.VariablePackage());

// Empty codebase
Codebase c = new Codebase(new Scripe.Env.Environment());

// Read-Eval-Print-Loop
string r = "";
while (true)
{
    try
    {
        Console.Write("Calc: ");
        if ((r = Console.ReadLine()) == "exit") break;
        c.Add(r);
        Console.WriteLine(" ==> " + c.Execute(p).ReturnValue);
    }
    catch (Exception ex)
    {
        Console.WriteLine(" ERROR: " + ex.Message);
    }
}

In nur 5 Zeilen haben wir hier (mithilfe der Scripe-internen und zweier für Lapicon geschriebenen Pakete) einen Prozessor geschaffen, der jede der folgenden Eingaben auswerten kann:

1+(4-6)*(3-4^5)+e
def variable = 7*8
def variableDurchZwei = <variable>/2
echo "(7*8)/2 = " & $(<variableDurchZwei>)

Und nun stelle man sich eine Internetseite vor, die eine gewisse Anzahl solcher Pakete anbietet. Scriptsprachen entwickeln einfach gemacht.

Soviel also von mir. Wann Scripe letztlich ganz fertig ist (und ich mich wieder den anderen Projekten wie LastSharp widmen kann), kann ich nur schätzen. Ist ein Monat in Ordnung?