Simpler Reader

Byte-Welt - Projekte / Projects Simple Read Worker
1

Motivation

Seit es Google Reader nicht mehr gibt bin ich auf Feedly ausgewichen. Allerdings will mir die Lösung nicht so ganz gefallen. Die App ist zwar IMHO top aber der Server-Teil nicht. Ich kann nicht gut suchen außer ich steige auf die pro. Version um und das größere Problem ist, ich kann nicht beliebig weit zurück gehen.

Zumindest zu dem Zeitpunkt an dem ich mich angemeldet habe wäre schön. Geht aber nicht :verzweifel:

Projektbeschreibung
Das Projekt gliedert sich daher in drei relativ einfache Teile.

Management Server
Hier kann man seine Feeds eintragen, sich registrieren, anmelden, etc.

Dieser Teil stellt auch eine REST-API zur Verfügung damit die Reader-App abfragen kann welche Artikel zum Lesen bereit stehen und mittels der, der Worker bekannt geben kann wann ein neuer Artikel zur Verfügung steht und welche Feeds er scrappen soll.

Es ist vom Management Server noch keine Zeile Code geschrieben. Wird allerdings in Node implementiert werden.

Reader App
Eine Android-App die simple HTML-Files anzeigt und über eine REST-API vom Management-Server erfährt welche Artikel es denn zum Lesen gibt. Diese werden dann in einer simplen WebView angezeigt.

Auch hier ist noch keine Zeile Code geschrieben. Wird aber klassischerweise eine mit Java geschriebene Android-App. Vermutlich in Form eines Eclipse-Projekts

Worker
Ein Tool das in periodischen Abständen nach sieht welche Feeds es gibt, diese ausliest und die Artikel scrapped. Scrappen bedeutet in dem Fall den Content extrahieren und in ein HTML-File schreiben. Der Standort des Files wird dann dem Management-Server mitgeteilt.

Ziel ist es, hier verschiedene Standorte anbieten zu können. Früher ging es, dass man im public Dropbox-Ordner HTML-Files ablegt die von außen sichtbar sind, aber der wurde leider gekilled :mad:

Also werden die Files im ersten Anlauf nur mal lokal gespeichert. Dort müssen sie dann per Webserver angeboten werden. Mögliche Optionen für die Zukunft sind also:

  • Dropbox dennoch implementieren. Denn Benutzer die den Public Folder noch haben können hiermit noch HTML-Files hosten.
  • Google Drive - Da müsste ich allerdings irgendwie den Preview-Link herausfinden.

Der Worker wird in Java geschrieben. Ich habe so einen ähnlichen Scrapper schon in JS mit Node geschrieben. Das lief aber nicht so rund wie ich mir das vorgestellt habe. Deshalb habe ich das ganze in Java neu implementiert. Bin zur Zeit zufrieden.

Ist ein Ant/Eclipse-Projekt. Im Moment ist das Ant-File nur dazu gut die Dependencies mit Ivy zu verwalten. Der Rest passiert in Eclipse. Wird aber noch besser :o)

Status

Projekt-Repositories
[ul]
[li]Worker-Repository[/li][li]Management Server N/A [/li][li]Android App N/A[/li][/ul]

Updates

[ul]
[li]2014-02-04 Worker der Feeds scrappen kann und deren Artikel lokal speichert ist in einer ersten Version fertig.[/li][li]2014-02-08 Ein Projektforum wurde von Byte-Welt gesponsert. [/li][/ul]

Was haltet ihr von der Idee?

2

Wie wäre es, das Protokoll vom Google Reader zu verwenden? Dann hätte man die Möglichkeit, die existierenden Clients zu verwenden. Dasselbe hat Feedly ja auch gemacht.

3

Gute Idee, aber ich hab’ auf die Schnelle keine brauchbare Doku zu der API gefunden. Die einzige Seite die ich gefunden habe war diese: https://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI

Und hier steht gleich am Anfang:

Note : This document is totally unofficial. You should not rely on anything on this document is you need an exact information. Google Reader API has not officially been released. This document has been made mainly by reverse engeneering the protocol.

Und das wiederum hört sich für mich eher so an als würde es nichts damit werden, außer du hast bessere Quellen.

4

Tatsächlich - da hatte ich wohl eine etwas falsche Erinnerung. Ich glaubte in einem c’t Artikel gelesen zu haben, dass Feedly zum google reader kompatibel sei.
Wahrscheinlich kann man bei der Standard-Feedly-App den API-Endpunkt nicht festlegen, denn dann hätte man auch dieses API implementieren können:
http://developer.feedly.com/v3/

Dort steht übrigens, dass das API dem vom google reader nachempfunden ist.

5

Dropbox und Google Drive gefällt mir in der Hinsicht nicht so gut. Also diese Dienste direkt anzusprechen.

Was mir hingegen gefallen könnte, wäre
http://remotestorage.io/

Das ist eine Spec, die ein Storage-Dienst bereitstellen können sollte.

Dafür gibt es verschiedene Implementierungen, unter anderem ginge es auch eine Impl. für Dropbox und Google Drive zu erstellen.
Aber man kann sich auch einen eigenen Server aufsetzen oder einen vertrauenswürdigeren Dienst wählen.

Auf das ganze aufmerksam geworden bin ich durch http://litewrite.net/
Das ist ein einfacher Text-Editor, der im Browser läuft. Dateien werden entweder im Browser selbst gespeichert (als unhosted web app: https://unhosted.org/ html5 bietet da ja mittlerweile einiges) oder man wählt einen remote storage Dienst.

Als Nutzer könnte man dann einen Feed und eine RemoteStorage-URL angeben die ein Worker nutzt um die Feeds abzugrasen und zu speichern.

Und anhand so einer RemoteStorage-Url würde ein Client dann auf die Daten zugreifen.

6

So wie der Worker im Moment konzipiert ist, ist das Ablegen vollkommen frei. Wichtig ist nur, dass der jeweilige Dienst dann eine öffentliche URL zurück gibt die per Browser angesehen werden kann. Wenn man was anderes möchte, kann man sich einen entsprechenden ExtractionProcessor schreiben. Ich werde auf jeden Fall einen schreiben der die HTML-Files per FTP auf einen Webspace schiebt. Soll für bplaced.net geeignet sein, ist dann aber völlig generisch. Das muss per Service passieren, welches man sich zwar selbst hosten kann aber ich werde für das hier auf keine noBackend-Strategie setzen und dazu gehört auch sowas wie remotestorage.io

Ob’s dann aus meiner Feder noch einen für Dropbox oder Google Drive einen geben wird steht noch nicht fest. Wie gesagt, das wäre zwar günstiger Storage aber mühsam einen echten Weblink zum HTML zu bekommen.
@cmrudolph - Das sieht ganz gut aus. Ich werde mich da orientieren aber bestimmt nicht alles implementieren.

7

Status-Update
Der Worker ist jetzt schon sehr weit gediehen. Folgendes ist passiert:
[ul]
[li]Encoding-Bug wurde gefixed. Worker verwendet nun Encoding-Detection und setzt den entsprechenden Meta-Tag im Ziel-HTML-File.[/li][li]FTP-Funktionalität hinzugefügt. Worker kann nun das extrahierte HTML per FTP hochladen und erzeugt einen Link den man sich im Browser anschauen kann.[/li][/ul]

Zusätzlich hat sich die Architektur etwas geändert um dann den Server-Teil leicht hinzuzufügen. Hier einmal ein Bild wie ein Originalartikel im Vergleich zum extrahierten Content aussieht:

8

Arbeitest du noch da dran?

9

Ja, aber es geht sehr schleppend vorran. Es steht das grundlegende Datenmodell für den Serverteil und ein paar Service-Calls funktionieren auch schon. Aber wie gesagt: schleppend.