Für mein neuestes Projekt wollte ich etwas einfaches, das eine saubere Struktur ermöglicht, aber nicht mit tausenden Dateien und riesigem Funktionsumfang daher kommt. Da ich schon vor einiger Zeit auf das PHP Fat-Free Framework gestoßen bin, und es einen sehr guten ersten Eindruck hinterlassen hat, habe ich mich entschlossen mir das Framework etwas genauer anzusehen. Sehr schnell war klar, dass es perfekt geeignet ist.

Features

Das PHP Fat-Free Framework verfügt über alle wichtigen Features, die mittlerweile so Standard sind:

• Routing Mechanismus (sehr einfach auch im MVC Style realisierbar)
• Datenbankzugriff (sogar mit einem mini ORM und einem MongoDB mapper)
• Template Engine
• Schnick Schnack wie: On-the-fly JavaScript/CSS compressor, CAPTCHA generator, OpenID, usw.

Die Template Engine konnte mich nicht ganz überzeugen, hier habe ich selbst Hand angelegt, eine kleine Hilfsklasse geschrieben und auf den in PHP integrierten Syntax zurückgegriffen. Ansonsten konnte das Framework in voller Linie überzeugen. Selbst eine Migration um eine Major Version funktionierte mit sehr geringem Aufwand, was mich doch sehr überrascht hat.

Anforderungen

Das Framework selbst ist sehr klein und wird mit einer einzigen 55KB großen PHP Datei beworben. Ganz richtig ist das aber nicht: Der Datenbankzugriff und weitere Funktionen wurden in Plugins ausgelagert. Nimmt man den gesamten Funktionsumfang, so hat man 27 Dateien mit einer gesamten Größe von 223 KB, was natürlich immernoch sehr schlank ist.

Ein bestimmter Server ist nicht erforderlich und das Manual bietet Anleitungen für das Umschreiben der URLs für den Apache Webserver, lighttpd und nginx. Einziger Wermutstropfen: Es benötigt mindestens PHP 5.3, was für einen simplen RSS Reader, der möglichst überall laufen soll eine doch recht hohe Anforderung ist. Gleichzeitig liefert diese Anforderung auch zahlreiche Vorteile, wie beispielsweise schlankeren Code durch Lambda-Funktionen oder der Einsatz von Namespaces.

F3 in der Praxis

Warum mir das Framework so zusagt, sieht man schnell, wenn man ein paar Zeilen Code sieht. Ein Beispiel ist das Routing:

require __DIR__.'/libs/f3/base.php';
F3::set('AUTOLOAD','libs/f3/|libs/|libs/WideImage/|models/|libs/twitteroauth|libs/FeedWriter');
F3::route('GET /', 'controllers\Index->home');
F3::route('GET /mark/@item', 'controllers\Items->mark');
F3::route('POST /source', 'controllers\Sources->add');
F3::route('PUT /source/@id', 'controllers\Sources->write');

Mit der ersten Zeile wird das Framework eingebunden. Mit der zweiten wird ein Autoloader registriert und die entsprechenden Inlcude-Pfade gesetzt (das Pipe Symbol | dient hier als Trennzeichen. Dann werden die Routen definiert. Das Fat-Free Framework unterstützt hierbei auch den REST Ansatz und einzelne URLs können mehrfach, je nach Art des HTTP Requests belegt werden. In diesem Beispiel wird bei einem GET Aufruf der URL / die Klasse \controllers\Index instaziiert und dort die Methode home aufgerufen.

Ähnlich einfach ist der Datenbankzugriff:

F3::set('DB',
	new DB(
		'mysql:host=localhost;port=3306;dbname=mysqldb',
		'admin',
		'p455w0rD'
	)
);
DB::sql('SELECT brandName FROM wherever');
foreach (F3::get('DB->result') as $row) {
	// whatever you want to do with $row
}

Um SQL Injection vorzubeugen, werden natürlich auch parametrisierte Queries unterstützt.

Ähnlich simpel ist das gesamte Framework gestrickt und meist bietet es verschiedene Wege etwas umzusetzen. Besonders elegant finde ich das Routing mit Lambda Funktionen:

F3::route('GET /about',
	function() {
		echo 'No subliminal messages here...';
	}
);

Lizenz und Downloads

Das Framework steht unter der GPLv3 Lizenz zur Verfügung, es wird aber auch eine kostenpflichtige, kommerzielle Lizenz angeboten. Das finde ich das einzige Manko, hier bietet beispielsweise das Zend Framework unter der MIT Lizenz sehr viel mehr Möglichkeiten.

Zur Projektseite des PHP Fat-Free Frameworks: http://fatfree.sourceforge.net/

An dieser Stelle vielen Dank an alle, die mich mit Sprachdateien versorgt haben und mir Feedback geben. Sofern ich die Zeit finde, versuche ich sinnvolle Neuerungen einzubauen. Die Performance zu optimieren (besonders das erstmalige Laden von rsslounge zu beschleunigen) war im aktuellen Update mein primäres Anliegen. Die Änderungsliste ist im Changelog zu finden.

Download: rsslounge 1.7

Zend_Translate bietet hier eine einfache Möglichkeit “Routen” zu erstellen. Das heißt man kann festlegen, welche Sprache alternativ verwendet werden soll. Dabei können sogar Ketten gebildet werden (z.B. wenn Französisch nicht gefunden wurde, dann in der deutschen Übersetzung suchen und wenn dort auch nichts gefunden wird, in der englischen). Wobei sich mir der Sinn von so einer Verkettung nicht ganz erschließt.

Das setzen einer Route ist sehr einfach. Folgendes Beispiel scanned ein übergebenes Verzeichnis nach CSV Dateien und übernimmt deren Inhalt als Übersetzung. Mit dem Key “route” wird definiert, wie die Sprachen verkettet werden sollen. In diesem Beispiel ist Englisch die Fallbacksprache für Deutsch und Französisch.

$language = new Zend_Translate(
            'csv',    // Typ der Quelle: hier csv Dateien
            'locale', // Quell-Verzeichnis
            'en',     // Standard Sprache
            array(    // Optionen
                'scan' => Zend_Translate::LOCALE_DIRECTORY,
                'route'     => array( 'de' => 'en', 'fr' => 'en' )
            ));

Der sauberste Weg ist es natürlich alle Schlüssel auf zu übersetzen. Beim Aufspüren von fehlenden Übersetzungen hilft Zend_Translate ebenfalls.

Die Problemstellung

Nun aber zum Thema: für ein aktuelles Projekt benötige ich, von meiner PHP Webapplikation heraus, den Zugriff auf einige Hardwarekomponenten. Zudem will ich einige Fremdbibliotheken verwenden, die sehr rechenintensive Aufgaben übernehmen und auch nur in C++ zur Verfügung stehen. Die Frage ist also: wie kann ich diese Komponenten an mein PHP Programm ankoppeln?

Für Java gibt es eine ganz gute Server Bridge, die innerhalb der Java Virtual Machine einfach einen kleinen Server startet, der XML Anfragen entgegen nimmt, stellvertretend ausführt und das Ergebnis, auch wieder über eine XML Kommunikationsschnittstelle, zur Verfügung stellt. Die nötige PHP Klasse wird ebenfalls durch den Java Server direkt zur Verfügung gestellt. Eine ähnliche Bridge Lösung bringt auch der Zend Server bereits out of the box mit.

Für C++ habe ich so eine Lösung nicht gefunden und als weiteren Ansatz überlegt, eine PHP Extension zu entwickeln. Sowohl für Linux, als auch für Windows, gibt es hier Tutorials (siehe “Extension-Entwicklung unter WAP“, “Wrapping C++ Classes in a PHP Extension” oder “Extension Writing Part I: Introduction to PHP and Zend“). Allerdings ist, neben den Tutorials, der ganze Vorgang nicht gut dokumentiert und scheinbar muss das Kompilat der Extension exakt dem des verwendeten PHP Kompilats entsprechen. Insgesamt also eher eine wackelige Angelegenheit.

Lösungsansatz

Meine Lösung ist hingegen pragmatisch und verfolgt eine eher losere Kopplung: Meine C++ Komponenten werden in ein eigenständiges Programm ausgelagert, das selbst, über einen gewöhnlichen HTTP Server, die benötigten Dienste zur Verfügung stellt. Dabei orientiere ich mich an dem REST Architektur Prinzip und binde jeweils eine Teil-Funktionalität an eine feste URL. Die Parameter und Rückgabewerte werden mittels JSON kodiert. Von PHP Seite aus, wird der Aufruf der C++ Komponenten sauber gekapselt, so dass für das PHP Programm der Eindruck entsteht, dass eine gewöhnliche Funktion aufgerufen wird.

Welche Vor- und Nachteile hat das Vorgehen? Zum einen ist die in C++ implementierte Funktionalität sauber gekapselt und von der Webapplikation getrennt. Dadurch wird die Software leichter wartbar. Durch eine saubere Schnittstellendefinition, kann die C++ Serverkomponente auch unabhängig vom Wissen über die PHP Applikation gepflegt werden. Zum anderen entsteht aber ein zusätzlicher Aufwand (mit zusätzlichen Fehlerquellen). Die Schnittstelle muss definiert und implementiert werden, ein Fehlerhandling muss durchgeführt werden und eine zusätzliche Serverapplikation muss gestartet werden, was hinsichtlich der Sicherheit berücksichtigt werden muss. Dennoch halte ich die Lösung für die eleganteste, denn sie nutzt genau die Vorteile der Vernetzung und der losen Kopplung aus. So könnte die C++ Komponente bei höherer Last auch leicht auf einen eigenen Server umgezogen oder unabhängig von der Webapplikation betrieben werden.

Implementierung

In der Theorie hört sich natürlich immer alles ganz nett an, aber wie sieht das mit dem HTTP Server aus? Hier gibt es eine hervorragende C++ Bibliothek, mit der sich ohne großen Aufwand eine solcher HTTP Server realisieren lässt. mongoose heißt das Wunderding, steht unter der MIT Lizenz unter Google Code zur Verfügung. Es unterstützt Windows, Linux und Mac OS X, bietet eine CGI Schnittstelle, SSL Verschlüsselung, ACL, eine saubere API und ist nicht größer als 60 kB. Die Dokumentation ist zwar recht knapp, aber dank Beispiele findet man sich schnell zurecht und auch die API Beschreibung ist vollkommen ausreichend.

Will man einen eigenen Server starten, so muss zuerst ein neuer Context erzeugt werden:

struct mg_context* ctx;
ctx = mg_start();

Mit mg_set_options, werden die Servereinstellungen geändert. Folgende zwei Zeilen deaktivieren das Directory Listing und setzten 8080 als Port.

mg_set_option(ctx, "dir_list", "no");
mg_set_option(ctx, "ports", "8080");

Aus Sicherheitsgründen erlaube ich nur einen Zugriff vom selben Rechner aus, also erlaube nur die IP Adresse 127.0.0.1:

mg_set_option(ctx, "acl", "-0.0.0.0,+127.0.0.1");

Mit mg_set_uri_callback kann ein Pointer auf eine eigene Funktion an eine URL gebunden werden. Diese wird aufgerufen, wenn der Client die URL aufruft, wobei die URL auch Wildcards enthalten kann.

mg_set_uri_callback(ctx, 'dosomething', &Server::dosomething, NULL);

Als dritter Parameter darf ein Pointer (void*) auf ein beliebiges Objekt übergeben werden. Die Callback Methode bekommt dazu alle notwendigen Parameter, wie die aktuelle Verbindung, den aktuellen Request und das zuvor übergebene Objekt (hier NULL) übergeben.

void Server::capture(struct mg_connection *conn,
 const struct mg_request_info *request_info,
 void *user_data) {
char* param = mg_get_var(conn, "param");
mg_printf(conn, "%s", "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n");
}

Mit mg_printf kann dann eine Antwort an den Client gesendet werden. Hier als einfaches Beispiel einfach nur ein OK (HTTP 200). In meinem Szenario wird hier der generierte JSON Text zurück gegeben. Mit mg_get_var können übergebene Parameter (POST, GET) ausgelesen werden. Wichtig: um memory leaks zu vermeiden, müssen diese mit mg_free wieder freigegeben werden.

Natürlich ist das nur die eine Hälfte. PHP muss jetzt auch Funktionen, auf dem Server, aufrufen können. Dazu kommt der Zend_Http_Client zum Einsatz. Dieser ist im Zend Framework enthalten, mit etwas Frickelei kann er aber auch aus dem Gesamtpaket heraus gepickt werden. Da ich aber das Zend Framework für die ganze Anwendung nutze, ist das Aufrufen der URL und das Decodieren des JSON Strings in einen Action Helper ausgelagert, der gleichzeitig eine einfache Fehlerbehandlung durchführt:

class JsonHttpHelper extends Zend_Controller_Action_Helper_Abstract {
   public function get($url, $params = array()) {
      try {
         $client = new Zend_Http_Client($url);
         foreach($params as $param=>$value)
            $client->setParameterPost($param, $value);
            $response = $client->request('POST');
            $res = Zend_Json::decode($response->getBody());
            if($response->isSuccessful()) {
               return $res;
            } else {
               return array("error" => "request not successfully: ".$res["error"]);
            }
      } catch(Exception $e) {
         return array("error" => $e->getMessage());
      }
 }
}

Bisher bin ich mit der Lösung sehr zufrieden. Besonders mongoose kann ich nur wärmstens empfehlen. Auch von der Verarbeitungsgeschwindigkeit ist das Ergebnis zufriedenstellend und kann sich sehen lassen. Um den Rahmen nicht zu sprengen, habe ich die serverseitige Generierung und Verarbeitung von JSON außen vor gelassen. Hier gibt es aber auch zahlreiche Bibliotheken, so dass die Suche nicht schwer fallen dürfte.

$autoloader =  Zend_Loader_Autoloader::getInstance();
$autoloader->registerNamespace('application_');

Wird die Zend_Application Klasse verwendet, so wird der Autoloader automatisch aktiviert (die Namespace’s müssen dabei in der Konfiguration gesetzt werden). Verwende ich dann eine Klasse, so wird der Name entsprechend aufgelöst, d.h. zu obigen Beispiel wird bei der Verwendung der Klasse “application_models_items” die Datei “application/models/items.php” eingebunden. Das Problem bei dieser Lösung: hat man ein sehr großes Projekt mit einer tiefen Hierachie, dann wächst der Klassenname entsprechend stark an. Bei meinem RSS Reader rsslounge hab ich das beispielsweise in Kauf genommen, da die Struktur nicht komplex ist. Zudem sieht man am Namen schon sofort, wo die Datei abgelegt ist und welche Funktion die Klasse übernimmt (application_models_items ist ein Model, dass sieht man sofort).

Seit der Version 1.8 bietet das Zend Framework einen eleganten Weg Klassen automatisch zu laden, dabei aber genau zu spezifizieren, wo die Klassen gesucht werden sollen. Dazu wird ein Namespace definiert und für verschiedene “Unter-Namespace” Pfade angegeben. Ein Beispiel veranschaulicht das Vorgehen:

$resourceLoader = new Zend_Loader_Autoloader_Resource(array(
 'basePath'  => APPLICATION_PATH . '/../einordner',
 'namespace' => 'Myproject',
 ));
 $resourceLoader->addResourceType('models', 'models', 'Model');
 $var = new Myproject_Model_Xyz();

Zuerst wird die Klasse Zend_Loader_Autoloader_Resource instanziiert. Dabei wird ein Namespace angegeben (im Beispiel “Myproject”) und definiert, in welchem Ordner die zugehörigen Dateien zu finden sind. In einem zweiten Schritt wird dann mit addResourceType ein “Unter-Namespace” definiert und angegeben in welchem Unterverzeichnis die Klassen liegen. Der Aufbau von addResourceType ist wie folgt:

 $resourceLoader->addResourceType($name, $ordner, $namespace);

Damit ist der Autoloader für alle Klassen mit dem Präfix “Myproject_Model_” aktiv. Im Beispiel wird eine Klasse Xyz geladen. Dabei wird für die Klasse “Myproject_Model_Xyz” die Datei “APPLICATION_PATH . /’../einordner/models/xyz.php” eingebunden. Es können beliebig viele “Unter-Namespace” definiert werden, was für eigene Klassen wie Models, Forms oder Validatoren sinnvoll ist.

Weitere Informationen und Beispiele sind im Manual zu finden. Keith Pope beschreibt anhand eines Beispiels sehr schön, wie er Zend_Loader_Autoloader_Resource in seinem Projekt verwendet (siehe “Seite 129ff, Zend Framework 1.8 – Web Application Development” von Keith Pope).

Dieser Weg Klassen automatisch zu laden gefällt mir ganz gut, weil er einfach ist und keine spezielle Loader Klasse nötig ist (die z.B. mittels einer statischen Funktion eine Klasseninstanz liefert). Natürlich offenbaren die Namespaces, welche mit PHP 5.3 eingeführt wurden neue Möglichkeiten, die ich mir auch noch genauer ansehen möchte. Oder gibt es eine noch schönere und elegantere Lösung? Dann bitte unbedingt kommentieren!

Die letzten Monate habe ich den Reader nun auf Herz und Nieren getestet und selbst jeden Tag verwendet. Zudem habe ich Feedback gesammelt und den Reader im Detail verbessert. So kann er jetzt beispielsweise auch fehlerhaftes HTML in Feed Einträgen verarbeiten und korrigieren. Die permanente Nutzung über die letzten Monate hat gezeigt, dass der Reader stabil ist und einwandfrei arbeitet. Daher habe ich mich entschlossen den aktuellen Stand als Version 1.0 zu veröffentlichen.

Ihr könnt die aktuelle Version jederzeit auf der Projektseite http://rsslounge.aditu.de herunterladen. Wer skeptisch ist, oder rsslounge noch nicht kennt, findet dort natürlich auch eine Demo Installation und kann alles erst einmal testen. Interessierte können auch die Entwicklung verfolgen oder einen Blick auf den Quellcode werfen. Hierfür gibt es eine Projektseite auf Google Code.

Feedback, Bugmeldungen oder Anmerkungen sind jederzeit willkommen. Ihr könnt hier kommentieren, das Kontaktforumlar auf http://rsslounge.aditu.de oder das Tracking System von Google Code verwenden.

Wen das Buch interessiert, der kann in Ralf seinem Blog an einem Gewinnspiel teilnehmen. Der Blog ist allgemein zu empfehlen: es gibt regelmäßig Updates und Infos zum Zend Framework. Ich werde mein Glück mal versuchen. Bin noch unsicher, ob sich die Anschaffung des Buchs lohnt. Bisher bin ich mit Ralfs Buch sehr zufrieden, dort sind alle wichtigen Informationen zu finden. Das was zur neuen Version hin noch fehlt, kann man auch problemlos im Zend Framework Manual nachschlagen. Aber als Gewinn wärs natürlich nicht schlecht…

Eine feine Sache, mein Poster ist heute angekommen und echt top:

Ein PHP Web Security Poster soll in Arbeit sein. Ich bin gespannt und werd jetzt einen passenden Platz für mein Poster suchen…

Zend Framework

Das Zend Framework ist ein objektorientiertes PHP Framework, das auf dem MVC Pattern basiert und viele viele Funktionen bietet. Das Zend Framework ist in diesem Blog ja ohnehin ein Thema und deshalb will ich an dieser Stelle dazu nicht schreiben. Einen ersten Überblick gebe ich hier, wobei natürlich innerhalb des letzten Jahres einiges hinzu gekommen ist.

jQuery

Auch jQuery ist mittlerweile kein Geheimtipp mehr und wie eine Umfrage des Webstandard Blogs zeigt, auch das beliebteste JavaScript Framework. Ich kann das gut verstehen, nachdem ich bisher auf prototype und script.aculo.us gesetzt habe, hat mich jQuery sofort überzeugt.

Alle weiteren JavaScript Bibliotheken basieren auf jQuery. Die Auswahl an Plugins ist schier unendlich und es gibt eine große Zahl an hervorragenden Projekten, die auf jQuery aufsetzen.

jQuery UI

Aufbauend auf jQuery gibt es jQuery UI, eine Bibliothek, die verschiedene Widgets und Funktionen bietet. Neben Widgets deckt jQuery UI das ab, was bei prototype durch script.aculo.us ergänzt wird: Drag n Drop, sortierbare Listen und animierte Effekte. In rsslounge basiert der Slider für die Priorität, das Drag n Drop der Feeds und Kategorien, sowie die Processbar für den ajaxbasierten Update auf dieser Bibliothek.

Impromptu

Es gibt ja eine ganze Reihe guter Lightbox Skripte. Für rsslounge habe ich aber ein LightBox Skript gesucht, das sich besonders gut für Dialoge eignet. Impromptu bietet hier eine einfache Möglichkeit Buttons zu setzen und eigene Funktionen an die verschiedenen Aktionen der Popup-Box zu binden. Lediglich bei der Positionierung der Box, die pauschal auf top:15% gesetzt ist, war ich nicht zufrieden. Allerdings hat man hier vollen Einfluss auf das CSS, so dass auch das kein echtes Problem ist. Eine sehr gute Alternative wäre die ModalBox gewesen. Diese basiert allerdings auf prototype.

Date Picker

Ein hervorragendes Skript für die Auswahl eines Datumbereichs ist der Date Picker von Stefan Petre. Date Picker für die Auswahl eines einzelnen Datums gibt es ja viele, so bietet jQuery UI hier auch ein grundsolides Widget. Aber wenn es darum geht einen Bereich zu wählen, wird die Auswahl plötzlich sehr klein. Der Date Picker hat ein schickes Design und kann sehr genau konfiguriert und mittels CSS gestaltet werden.

jgrowl

jgrowl orientiert sich an dem Benachrichtigungssystem von Growl, welches für Mac OS X verfügbar ist. Es zeigt Benachrichtigungen in einer kleinen Box am Bildschirmrand an. rsslounge nutzt dieses Skript nur recht selten, für Fehlermeldungen und wichtige Informationen ist es aber hervorragend geeignet.

Ajax Upload

Mit Hilfe dieses jQuery Plugins können bei rsslounge OPML Dateien importiert werden. So lässt sich der Dateiupload mit einem Klick auf den entsprechenden Menüpunkt starten, ohne das explizit ein neu Laden der Seite oder das Datei Eingabefeld nötig ist.

Tipsy

Das Plugin Tipsy ermöglicht beliebige ToolTipps zu erstellen. Diese verwende ich für den Eingabedialog von neuen Feeds. Manchmal bleiben die ToolTipps noch hängen, hier muss ich also nochmal genauer testen. Der erste Eindruck ist aber sehr gut und die zusätzlichen Informationen sind für Neulinge dann doch eine gute Hilfe.

SimplePie

Das Herzstück von rsslounge ist die Bibliothek SimplePie. Diese PHP Bibliothek ermöglicht es sehr einfach RSS Feeds zu lesen und zu verarbeiten. Ich habe mich für SimplePie und nicht für Zend_Feed entschlossen, da es um einiges ausgereifter ist, mit keinem Feed Probleme hat und sich bereits in vielen Applikationen bewährt hat. Ein erster Test hat dann auch gleich gezeigt das SimplePie schwer zu toppen ist. rsslounge selbst ist so aufgebaut, dass sich problemlos SimplePie durch eine andere Bibliothek ersetzen lässt (oder eine zweite Bibliothek optional gewählt werden kann), bisher gab es aber keinen Grund dafür. SimplePie besteht lediglich aus einer Datei und einer Hand voll Klassen.

WideImage

Für das Erzeugen der Thumbnails verwende ich die Bibliothek WideImage, welche sich zwar noch in Beta befindet, aber im Test super funktioniert. WideImage basiert auf der GD2 Erweiterung und kapselt alle Funktionen in eine Klasse und erlaubt es komfortabel Bilder zu laden, zu verkleinern oder anderweitig zu verändern. Ein Beispiel wie das dann aussehen kann:

wiImage::load('image.png')->resize(50, 30)->saveToFile('new-image.jpg');

Icons

An der Stelle will ich auch nicht die Icons vergessen. Diese stammen von DryIcons, welche die Sticker Icons unter einer Free Lizenz anbieten, sowie vom Smashing Magazine. Letztere erlauben eine freie Verwendung der Icons (auch für kommerzielle Zwecke, ohne Einschränkungen).

Die Liste ist ganz schön lange, aber bestätigt mich darin laufend gute Skripte zu sammeln. Besonders Funktionalitäten, die sich gut kapseln lassen, oder kompliziert zu entwickeln sind, sind für eigene Projekte eine wahre Bereicherung.

rsslounge ist ein kostenloser, webbasierter RSS Feed Reader. Der Reader ist kein gehosteter Service und muss auf dem eigenen Webserver installiert werden.

Features:

• Vollständiger RSS Reader
• Unterstützt Bilder und Fotoblogs
• Setze Prioritäten und filtere Feeds und Einträge
• Einfache ajaxbasierte Oberfläche
• Unterstützt auf Ajax basierende, sowie Cronjob Updates
• Offenes Pluginsystem zum Hinzufügen eigener Datenquellen

Also keine falsche Scheu, einfach saugen und austesten. Über Feedback, egal welcher Art, bin ich dankbar und freue mich über eure Meinungen, Gedanken, Ideen und Probleme.

Downloaden könnt ihr rsslounge hier.

Wer sich für den Quellcode interessiert, der kann sich auf der Google Code Seite informieren. Dort findet ihr ein Wiki, das SVN Repository und weitere Infos. Die Seite werde ich nach und nach mit weiteren Infos befüllen.