Was ist der Python Desktop Server?

Nehmen wir einfach mal den Namen auseinander

Der einfachste Ansatz geht erstmal vom Namen des Programms aus. Was kommt drin vor? Python. Desktop. Server. Python - das ist klar, wenn man sich anschaut, was alles installiert wird, wenn man den Python Desktop Server zum Laufen kriegen will. Jede Menge Python. Der Python Desktop Server ist also auf jeden Fall erstmal ein grosser Haufen Python-Code. Wenn zu nichts anderem kann er immer noch zur Belustigung anderer Programmierer herhalten.

Als nächstes kommt Desktop. Desktop deshalb, weil der Python Desktop Server normalerweise (aber eben nur normalerweise, es geht auch anders, dazu später mehr, falls ich es nicht vergesse) auf dem Desktoprechner des Benutzers läuft. Also normalerweise nicht irgendwo draussen im Netz, womöglich bei einem Provider, sondern auf der eigenen Arbeitskiste. Da wo die Action läuft.

Und als drittes Server. Server? Wozu braucht ein normaler Anwender einen Server? Nunja, ein privater Server ist durchaus praktisch: er läuft im Hintergrund, wird bei Systemstart mitgestartet (wenn man das so einrichtet natürlich nur) und braucht erstmal keine komplexe Oberfläche um seinen Job zu erledigen. Natürlich hat der Python Desktop Server eine Oberfläche. Aber die gestaltet sich als Weboberfläche. Das hat den Vorteil, das man sich gleich im richtigen Werkzeug bewegt - denn beim Python Desktop Server dreht sich alles um das Web, um Webinhalte und die Produktion und Nutzung derselben (aber auch dazu später mehr).

Was bringt also die Kombination? Einen in Python geschriebenen Server, der nur für den Benutzer da ist und dem seine Dienste zur Verfügung stelle. Dein ganz privater Webserver mit Content-Management-System und allem was das Herz begehrt. Sagte ich schon das der in Python ist? Bestimmt . Der Vorteil dabei ist, das er dadurch noch viel persönlicher wird, als wäre er als Binärprogramm implementiert: aller Source liegt vor, steht zur Verfügung. Wenn also die Konfigurationsmöglichkeiten nicht ausreichen, schreibt man ihn eben um.

Das Wort Desktop kann man auch noch anders auslegen: der Python Desktop Server stellt einen Desktop, einen Schreibtisch bereit. Und zwar für Webarbeiten. Was das heisst? Kommt später.

Schauen wir uns mal die technische Seite an

Ein paar technische Aspekte habe ich vorhin ja schon genannt. Der Python Desktop Server ist ein in Python geschriebener Webserver mit einer Modulstruktur, über die man verschiedenste Module einklinken kann (dazu später mehr).

Ansonsten ist er aber technisch recht interessant aufgebaut. Zu allererst ist da der Webserver: Medusa. Ein fertiger Webserver in Python dessen Besonderheit ist, das er sehr wenig Systemlast braucht (bedingt durch seine pfiffige Konstruktion). Dadurch belegt der Python Desktop Server im Leerlauf nur sehr wenig Resourcen, kann also ohne Probleme im Hintergrund mitlaufen.

Dieser Webserver dient vor allem dazu das die Oberfläche (die ja als Weboberfläche gestaltet ist) realisiert werden kann. Allerdings bietet er noch ein weiteres Feature an, das eher ungewöhnlich ist: alle öffentlichen Methoden der Werkzeuge (Module) die man einklinkt, sind über XML-RPC oder alternativ über SOAP erreichbar. Man kann über diese Schnittstelle sehr gut Python Scripte (oder Perl Scripte, Applescript Scripte oder ganze Objective-C Anwendungen oder welche Sprache auch immer gewünscht ist) erstellen, die auf den Desktopserver zugreifen und zum Beispiel Notizen erstellen oder Daten abfragen. Das ganze geht - bei entsprechender Konfiguration - sogar über Rechnergrenzen hinweg.

Hinter den Webserver gehängt ist eine Multitasking-Architektur die es dem Python Desktop Server erlaubt Dinge zu tun, wenn er eigentlich mit was anderem beschäftigt ist. Alle längeren Aktivitäten (zum Beispiel herunterladen und analysieren von Newsfeeds) geschehen dadurch im Hintergrundund blockieren die Oberfläche nicht. Der Python Desktop Server reagiert also fast immer sehr zügig, auch auf kleineren Rechnern (mein G3 hat nur 350 Mhz, ist also kein Renner, aber der Python Desktop Server läuft tadellos darauf).

Unter den Webserver gepackt ist eine Datenbank, in der die Konfigurationsparameter und die Nutzdaten des Systems gespeichert werden. Diese Datenbank (Metakit - wird übrigens von Apple auch im Systemadressbuch in OS X benutzt) ist sehr schlank, schnell und robust. Ideal für ein System das möglichst unauffällig in seinen Laufeigenschaften sein soll. Diese Datenbank wird durch eine einfache und allgemeine Schnittstelle für XML Exporte und Importe ergänzt, die zum Beispiel für Backups benutzt wird (die dann wieder automatisch auf den Community-Server hochgeladen werden können, von wo sie dann auch wieder per Restore geladen werden können, wenn mal was schief geht).

Alle Inhalte können (und werden meistens auch) in HTML-Seiten umgewandelt und auf einen Community-Server hochgeladen. Der Community-Server ist eigentlich nur eine etwas anders implementierte Version eines Webservers mit einer Upload-Schnittstelle und ein paar standardisierten CGIs (zum Beispiel für Kommentarfunktionen oder ein eMail-Formular). Zusammen sind die beiden aber ein unschlagbares Team - der Community-Server sorgt für die Auslieferung der öffentlichen Seiten, der Desktop-Server verwaltet die Erzeugung dieser öffentlichen Seiten. Und zwar ganz automatisch im Hintergrund. Jede Änderung wird innerhalb von wenigen Sekunden umgewandelt und rausgeliefert.

Dazu kommen sehr flexible Plugin-Möglichkeiten und gute Erweiterbarkeit. Zum Beispiel stehen für Texte zwei Formatiermöglichkeiten zur Verfügung, einmal strukturierter Text (normaler Text, der automatisch in HTML gewandelt wird) und HTML. Beide benutzen die Kürzel um häufige Begriffe kurz eingeben zu können genauso wie eine spezielle HTML-Makrosprache, mit der man alle Funktionen des Systems (die gleichen, die man auch extern per XML-RPC oder SOAP aufrufen kann!) in HTML-Seiten einbinden kann. HTML-Seiten basieren also fast immer auch auf Datenbankinhalten, manche Seiten sind nur Datenbank.

Schlussendlich gibt es noch massig Verwaltungsmodule und Funktionen. Ausserdem werden alle vorhandenen Funktionen im System selber an allen Ecken und Enden benutzt - z.B. die XML-Exporte/Importe für den Backup/Restore von Tabellen, die dann mit den normalen Kopiermethoden auf den Community-Server kopiert werden.

Betrachten wir mal die mitgelieferte Software

Der Python Desktop Server kommt mit einer grossen Sammlung fertige Module, die in den Python Desktop Server eingeklinkt sind. Die für einen Benutzer wichtigsten werde ich hier kurz beschreiben. Dazu wandere ich die Menüleiste oben von links nach rechts ab.

Das Weblog verwaltet Einträge im zentralen Weblog. Dieses Weblog kann allerdings durch Kategorien erweitert werden, kann also im Prinzip mehrere Weblogs verwalten (Beiträge können auch in mehrere Kategorien gehen). Zusätzlich ist das Weblogwerkzeug auch noch über spezielle Hook-Techniken erweiterbar. Das wird zum Beispiel vom TopicExchange-Werkzeug benutzt um eigene Dialogelemente in die Seite einzubringen.

Direkt neben dem Weblog (in der Standardkonfiguration) ist das Bilderwerkzeug. Damit kann man fotografische Notizbücher führen. Im Prinzip ist es wie das Weblog strukturiert, aber es gibt keine Kategorien. Ausserdem hat - im Gegensatz zum Weblog, wo jeder Beitrag mit dem gleichen Template dargestellt wird - jedes Bild sein eigenes Template. Damit man die Gestaltung dem Bild anpassen kann. Die Übersichtsseiten sind aber ziemlich identisch mit dem klassischen Weblog.

Dann kommen die Fremdtexte. Damit kann man Texte in die Homepage einbauen, die aus fremden Werkzeuge kommen - z.B. mit BBEdit editieren. Oder mit Tinderbox (ein Outliner für den Macintosh) generieren. Oder wie auch immer erstellen - z.B. auch mittels eines Cronjobs aus Systemdaten oder was auch immer einem einfällt. Das Besondere hier ist, das der Python Desktop Server diese Texte in sein eigenes Layout integriert (man kann Makros dazwischenhängen, wenn man das Layout programmatisch anpassen muss) und die Seiten dann hochlädt. Nicht immer will man alles im Webbrowser editieren, dann kommt das Fremdtextewerkzeug zum Zuge.

Jetzt kommt ein anderer wichtiger Bereich: die Zeitung, oder auch der Aggregator. Hier werden Newsfeeds (Nachrichtenkanäle) aus dem Netz geladen und die Einträge in einer Datenbank gesammelt. Man kann sie dann dort lesen, interessante festhalten, uninteressante löschen. Neue Beiträge werden speziell gekennzeichnet, so das man sie sofort erkennt. Ausserdem kann man Beiträge in das Weblog übernehmen und dort kommentieren. Zusätzlich gibt es einige Werkzeuge zur Analyse von Newsfeeds, da diese sich oft eben nicht in allen Punkten an die Standards halten.

Nach der Zeitung kommen die Kürzel. Hier kann man Kurztexte hinterlegen, die durch längere ersetzt werden. Zum Beispiel sind in den Standardkürzeln Smileys hinterlegt, die durch entsprechende Images ersetzt werden. Praktisch für immer wiederkehrende längere Namen oder ähnliches.

Als nächstes kommen Textbausteine. Diese dienen in Layouts und Texten als Einschübe. Man kann damit grössere Textblöcke erstellen. Bausteine nutzen die vollen Fähigkeiten der Makrosprache und können Parameter übergeben bekommen, auf die sie entsprechend reagieren. Sie haben Ähnlichkeit mit den Makros, dem nächsten Punkt im Menü. Makros sind in Python geschriebene Elemente, die genauso benutzt werden können wie Bausteine. Als Daumenregel: wenn eine Hilfsfunktion hauptsächlich HTML-Source generiert, sollte man einen Baustein benutzen. Ist die Hilfsfunktion eher auf komplexeren Code ausgelegt, bietet sich ein Makro an.

Als letzter Punkt kommen die Einstellungen. Hier kann man das ganze System konfigurieren. Einfach mal alle Punkte durchklicken und angucken.

Rechts an der Seite unter dem Kalender sind noch eine ganze Reihe weiterer Werkzeuge, die verschiedene Hilfsfunktionen realisieren wie den Download von Daten oder den Upload der erzeugten HTML-Seiten. Ausserdem Statusübersicht, eine automatisch generierte Dokumentation der veröffentlichten Methoden der Werkzeuge (für Makros und ähnliche Zwecke, oder auch für XML-RPC und SOAP Aufrufe) und ein Werkzeug zur Verwaltung von Themes (Layouts).

Über Makroaufrufe in den Templates und Texten können aber alle Werkzeuge auf Funktionen der anderen Werkzeuge zurückgreifen. Weblogeinträge können zum Beispiel Bilder aus dem Bilderwerkzeug anzeigen. Oder Texte können Beiträge aus dem Weblog mit Bildern kombiniert als eine einzelne Themenseite darstellen. Und dazu vielleicht noch thematisch ausgewählte Links aus der Zeitung dazunehmen.

Und was kann ich mit dem ganzen Zeug machen?

Mir doch egal . Aber ein Anfang wäre zum Beispiel ein eigenes Weblog zu publizieren. Oder andere Weblogs zu lesen (über die Aggregator-Funktion). Oder eigene Webanwendungen zu schreiben, die auf dem Python Desktop Server aufbauen. Die Möglichkeiten sind massig.

Ich zum Beispiel benutze nahezu alle Module aus dem Python Desktop Server (klar, ich bin ja auch der Autor). Die Nutzung vom Python Desktop Server gestaltet sich wie folgt:

Ich lese jeden Tag so ca. 100 Newsfeeds aus dem Web. Natürlich will ich nicht alle Newsfeeds durchklicken, das wäre zu viel Arbeit und würde zu viel Zeit in Anspruch nehmen. Also abonniere ich die im Aggregator und gucke nur diesen durch. Dort sehe ich, was mich interessieren könnte und ich lesen dann ganz gezielt diese Beiträge.

Interessante Beiträge lese ich aber nicht nur, ich kopiere sie auch in mein Weblog rüber - meistens nur den Link und Titel, der Text kommt dann von mir dazu. Was mir dazu eben so einfällt. Teilweise dient das nur dazu mir Links zu merken, manchmal ärgere ich mich über etwas und schimpfe darüber oder finde etwas witzig und schieb es zur allgemeinen Belustigung raus. Im Prinzip ist es für mich die Apfelsinenkiste im Park genauso wie ein Logbuch gefundener Webseiten. Aber es ist kein Tagebuch! (und es gibt keine "Wertschöpfungskette", bevor da einer nach fragt ).

Zusätzlich bin ich Hobbyfotograf. Meine normalen Bilderseiten sind unter http://hugo.f-2.org/ und http://leicaesk.de/ zu finden. Aber ich will manchmal auch einfach nur Bilder in einen Zeitlichen Kontext stellen, dann gehen die in mein Bilderblog auf http://hugo.muensterland.org/pictures/ - dort ist im Prinzip ein fotografisches Notizbuch.

Das ganze wird mit verschiedensten Tools erweitert. Zum Beispiel benutze ich die Fremdtexte dazu um mit Tinderbox meine Ideenliste auf dieser Seite zu pflegen - Tinderbox erzeugt ein HTML-Fragment, das vom Python Desktop Server dann in eine volle Seite umgesetzt und dann hochgeladen wird.

Teilweise brauche ich dafür Makros und Textbausteine, dazu benutze ich dann die entsprechenden Werkzeuge - Makros zum Beispiel werden benutzt um defekte RSS-Feeds zu reparieren oder um Texte umzuformatieren oder einfach nur um kleine Schnipsel HTML zu generieren, die mir die Seitenerstellung erleichtern. Die Makrosprache vom Python Desktop Server für Texte ist also leicht erweiterbar - hier wird der Python Desktop Server zum Content-Management-Werkzeug. In die gleiche Kerbe schlagen die Kürzel, die auch nur eine Erleichterung bei der Eingabe darstellen.

So, das wars erstmal. Ich hoffe das jetzt ein bischen klarer ist, was der Python Desktop Server überhaupt darstellt. Achja, wem eine gewisse Ähnlichkeit zu Radio Userland auffällt: erwischt. Der Python Desktop Server ist eim Prinzip ein Open-Source-Clone zu Radio Userland. Viele Funktionen sind sehr ähnlich ausgelegt, die Architektur hat auch sehr grosse Ähnlichkeit. Allerdings belegt der Python Desktop Server deutlich weniger Resourcen im System als Radio Userland.

Achja, einen Hoster braucht man natürlich auch. Dieser muss einen Community Server betreiben, der das XMLStorageSystem Protokoll implementiert. Das kann ein Radio Community Server wie der von Radio Userland oder von Salon sein, oder ein Python Community Server wie der auf http://pycs.net/ oder http://muensterland.org/