[wiregate] Plugin: Log-Meldung -> RSS

[Chris M.]

Bevor ich hier Arbeit wiederhole:

Gibt's schon ein Plugin bzw. eine Funktion für Plugins das Log-Meldungen so ablegt, dass diese dann per RSS (z.B. in der CometVisu) abgerufen werden können?

[makki]

Nicht das ich wüsste, aber es stünde definitiv auf meiner Liste (zur Umsetzung gäbe es noch einge Fragezeichen im Kopf! ich dachte an einen Hash mit GA->Meldungstext)
Wann man zur Umsetzung dieses Punktes schreitet steht aber in den Sternen..
Nur mit genau diesem Hintergedanken habe ich das RSS-Plugin eigentlich gemacht, wem zuerst langweilig ist oder den es zu sehr nervt

Makki

[Chris M.]

Meine Implementierung hätte ich spontan so gemacht:

Web-Service in PHP das die einzutragenden Logs entgegennimmt, ggf. (per CRON) alte Einträge löscht und natürlich per RSS wieder ausspuckt.

Das Plugin müsste dann nicht viel mehr machen als eine passende URL aufrufen, wie z.B.:

http://wiregate/rsslog.php?c=<der Content>&t[]=<Tag[s]>

Als Feed könnte man dann z.B. nach Tags filten...

Um hier mit Gleichzeitigkeit keine Probleme zu bekommen (insb. beim Bereinigen per CRON), hätte ich eine Datenbank-Lösung genommen. Spontan SQLite. (Ggf. konfigurierbar zu MySQL für Leute die ein NAS betreiben und dort Gigabyte weise die Logs aus dem letzten Jahrzehnt haben wollen. Z.B. ob und wann am 12.05.<lange her> jemand geklingelt hat...)

Da die nicht installiert ist: Ist dieses Vorgehen zielführend? Wollen wir SQLite zum Default auf dem WireGate machen?
Alternativen?

[swiss]

Ich wäre total für die Einführung von SQLlite.

Eventuell könnte man das dann mit PERL-Plugins mitbenutzen und somit ohne umständliche Hashgeschichten Daten zwischenlagern und wieder einlesen.

[Chris M.]

Eventuell könnte man das dann mit PERL-Plugins mitbenutzen und somit ohne umständliche Hashgeschichten Daten zwischenlagern und wieder einlesen.

Genau, und ggf. sogar direkt per Plugin das Log dort reinschieben, ohne Umweg über ein Web-Interface

[swiss]

@makki

Gibt es eigenlich ein Paket für DBD::SQLite das mit dem WG läuft?

[Bodo]

Hoi

Klaro Debian -- Details of package sqlite in sid

[swiss]

Hallo Bodo

Danke für die schnelle Antwort. Leider ist das nicht das gleiche Modul. Also fand ich bis jetzt noch keine Codebeispiele da die alle auf DBD aufbauen.

Hättest du da eine Dokumentation dazu?

[Chris M.]

Ich glaube, Du brauchst eher das Paket libdbd-sqlite

[swiss]

Hallo Chris

Auch das Paket habe ich installiert. Leider funktioniert die einbindung nicht. In den Beispielen wird immer:

[COLOR=#2040a0]use[/COLOR] [COLOR=#2040a0]DBI[/COLOR][color=#4444FF];[/COLOR]

...verwendet. Hmm... Aber es muss ja nicht genau dieses Modul sein. Hauptsache es ist ein Modul dass vernünftig beschrieben ist und zu dem es ein paar Codebeispiele gibt.

[Chris M.]

Lassen wir erst mal Perl beiseite. Im SVN unter openautomation/tools/rsslog/rsslog.php ist nun mal die erste Version, die PHP und SQLite verwendet.


Am WireGate ist dazu im Terminal per

apt-get install php5-sqlite

(oder per beliebig anderem Mechanismus) das Paket php5-sqlite nach zu installieren.


Ich habe die rsslog.php erst mal direkt unter /var/www gelegt. Folglich kann ich nun per

http://wiregate/rsslog.php?c=Foo

einen neuen Log-Eintrag mit dem Titel "Foo" generieren.


Und unter

http://wiregate/rsslog.php

kommt nun ein RSS2.0 Feed mit allen Logs.


(Test bisher nur schnell im Firefox. In den CometVisu-RSS-Reader hab ich's noch nicht eingebunden)


ToDo:

• Sicher viele Bug fixe
• Tags implementieren
• Web-Interface für CRON zum Löschen alter Einträge erstellen

[Bodo]

Hättest du da eine Dokumentation dazu?

Hoi Patrik

Ich war beschäftigt, sorry. (Mein WG zickt immer noch rum seit einem update und der EibPC hat dadurch einen Schluckauf bekommen, bis ich den Fehler gefunden hatte )
Da gibt es wohl veschiedene libs für sqlite, sorry ich wollte es gerade ausprobieren als der Schlamassel los ging (eben wegen dem aptitude update usw.)

[makki]

Da die nicht installiert ist: Ist dieses Vorgehen zielführend? Wollen wir SQLite zum Default auf dem WireGate machen?

Ehrlich, hab mir dazu noch keine Meinung gebildet (bisherige Anforderungen im Job fragten eher, ob 400 Tabellen mit 4000x Index bei >4 Mio Datensätzen gehen.. iSv WG ist selbst MySQL einfach totaler overkill..)
SQLlite klingt gut, ich denke das wäre die richtige Richtung wenn es denn um relevante Datenmengen geht (sonst ist ein Textfile mit CR/LF nämlich immernoch 100.000x effizienter)

Will sagen, für eine zweistellige Anzahl an Meldungen muss man nicht wirklich eine relationale DB bemühen; SQLlite wäre ein gangbarer mittelweg aber vermutlich immernoch totaler overkill, um eine handvoll Meldungen zu speichern und als RSS auszuspucken: Datenbanken verwende man für datenmengen.. unter hundert sind die nicht da
So ein Textfile (XML, Json, ...) hat durchaus auch Vorteile, wenn nur ein bisschen pillepalle drinsteht..

Makki

[Chris M.]

iSv WG ist selbst MySQL einfach totaler overkill..)

Sehe ich auch so

Will sagen, für eine zweistellige Anzahl an Meldungen muss man nicht wirklich eine relationale DB bemühen; SQLlite wäre ein gangbarer mittelweg aber vermutlich immernoch totaler overkill, um eine handvoll Meldungen zu speichern und als RSS auszuspucken: Datenbanken verwende man für datenmengen.. unter hundert sind die nicht da
So ein Textfile (XML, Json, ...) hat durchaus auch Vorteile, wenn nur ein bisschen pillepalle drinsteht..

Jain.

Mengenmäßig und daher bzgl. für die Performance entscheidend würde eine Text-Datei locker reichen. Und klar hat die den Vorteil, dass ich die mit jedem Editor (inkl. sed) bearbeiten kann.

Aber, und für mich hier entscheidend, ist eine Text-Datei erst mal rein Single-User. Wir haben hier aber eine Client-Server-Anwendung mit potentiell mehreren Usern.
Wenn nun zwei Meldungen gleichzeitig geschrieben werden (auch auf dem Single-Core WireGate könnte ja der entsprechende lighttpd/PHP-Thread vom anderen unterbrochen werden) und noch viel schlimmer per Cron gleichzeitig die alten Einträge gelöscht werden, dann ist eine pure Text-Datei an der Grenze. Und ein SQLight nimmt mir hier das Denken (und noch viel besser: Debuggen!) ab, der wird das schon passend lösen.

[makki]

Aj, ich nehm ja die SQLlite-nummer
Das ist auf einem WG mit >>50% freiem RAM&Flash eher relativ egal; naja und absteigen werden wir auch nicht also bleibt es egal..
(ich wollte ja nur anmerken das man für 50 Textmeldungen nicht wirklich eine DB mit 500% Overhead bemühen müsste - aber wie sagt man so schön: warum leckt sich der Hund die Ei** - weil er es kann! So ist es hier: wir können und haben genug )

Makki