ToDo Liste und Ideensammlung

Unter diesem Punkt werden offene Probleme in PyDS gesammelt. Kann also auch durchaus mal leer sein

PyDS: Bug im AggregatorTool bei HTTP Status

Das AggregatorTool berücksichtigt nicht alle HTTP-Status korrekt. Folgende sollten überarbeitet werden:

301 - permanente Umleitung, also die RSS-Adresse anpassen im Feed, damit danach immer auf die neue Adresse zugegriffen wird.

410 - explizit gelöschte Adresse (gone). Also den RSS-Feed deaktivieren, evtl. sogar löschen?

PyDS: Bug bei Delete verschiedener Objekte

Es sollte eine Confirmation kommen, wenn man einen Eintrag löschen will. Folgende Tools haben dieses Problem:

NavigationTool

MacrosTool

NuggetsTool

PyDS: Bug im AggregatorTool bei relativen Links

Relative Links sind nicht unterstützt, sollten aber bezogen auf den Feed-Link aufgelöst werden (nicht den rss-Link, sondern SOURCEURL).

PyDS: Bug im MeshTool index_html

jmhodges hat eine Fehlermeldung im MeshTool:index_html gesehen. Nach Analysen wird bei ihm bei der Hash-Zuweisung toolHasSig[tool] = False ein Nugget gesucht, wenn das über die Nuggets läuft. Klingt so, als ob sein Python anders wäre als mein Python. Dazu müsste man mal __getattr__ in NuggetTool aufbohren, so das es logged, welches falsche Nugget abgefragt wird. Vielleicht ist es ja sowas wie __repr__ oder eine andere interne Funkion? Bei mir ist das bisher nicht nachvollziehbar.

PyDS: Bug im ExternalStoryTool bei Upstreaming

jmhodges hat ein Problem mit dem Upstreaming von external stories. Die werden zwar im Index angelegt, und der Index wird auch hochgeladen, aber das File selber fehlt. Bisher von mir nicht nachvollziehbar.

PyDS: Bug bei Online/Offline Switch

In Preferences Panels (aufgefallen ist es mir im NavigationTool) kann man nicht den Online/Offline Switch benutzen - da kommt ein Attributfehler. Konnte ich aber nicht wieder reproduzieren bisher.

PyDS: Bug im Aggregator bei drf-Wiki-Feeds

Der drf-Wiki-Feed produziert seltsamerweise immer mal wieder die neueren Elemente als unbekannt, obwohl die sicherlich schon längst in der History stehen müssten. Möglicherweise hat es was damit zu tun, das dieser Feed nur sehr selten aktualisiert wird. Das müsste ich näher debuggen, um rauszukriegen warum der das macht - das ist nämlich der einzige Feed mit diesem Problem.

PyDS: Bug im Aggreagator bei utf-8 noch da

Der Feed von Kai Suhrendorf funktioniert nicht, die Umlaute in utf-8 Kodierung werden nicht korrekt aufgelöst. Eine einfache Umsetzung nach Latin-1 ist auch nicht möglich, da dort Zeichen ausserhalb Latin-1 benutzt werden. Das ganze kann eigentlich nur dadurch gelöst werden, das PyDS immer nach Außen utf-8 kommuniziert und nicht mehr iso-8859-1!

Das erfordert aber eine grössere Umorganisation, da dadurch die Grundstruktur von PyDS angegangen wird. Allerdings wäre es die sauberste Variante, da Unicode-Unterstützung in der Ausgabe bedeutet, das ich komplette Zeichensätze mixen kann - was ja auch schon heute geht, wenn PyDS komplett auf utf-8 umgestellt ist. Allerdings könnten manche Browser (speziell warscheinlich Textmode-Browser) mit dem utf-8 nicht wirklich gut klarkommen? Ausserdem bekomme ich Probleme mit den Übersetzungsfiles, die derzeit ja nicht in utf-8 sind und deshalb falsche Zeichensätze haben. Im Prinzip müsste die Zeichensatzunterstützung auf einen getrennten Input-Zeichensatz (für die Übersetzungsfiles), einen Output-Zeichensatz (für das Rendering sowohl für Cloud als auch Desktop) und einen Speicherzeichensatz (für die Ablage in der Datenbank) getrennt werden.

Alternativ könnte ich mir vorstellen, das Feeds mit Unicode-Inhalten um diese bereinigt werden. Dabei können die Unicode-Anteile dann in Ersatzdarstellung dargestellt werden, die nach Latin-1 wandelbaren Inhalte hingegen direkt gewandelt werden.

Wichtig dabei ist natürlich die Berücksichtigung des konfigurierten Zielzeichensatzes - nur wenn die Kodierung in den Zielzeichensatz nicht möglich ist, darf diese Sonderkonvertierung angewendet werden! Die Frage ist hier, ob es noch Zeichensätze gibt, die mehr als 8bit pro Zeichen haben, aber nicht alle Zeichen aus Unicode abbilden können. Wenn ja, wäre der Alternativweg nicht so günstig.

Parsehooks erleichtern die Nutzung von Feeds, die Spezifika enthalten.

Parsehook für Trackback

Bei MoveableType kann man die Postings runterladen und dann reingucken, da stehen Trackback-Links drin. Damit könnte ich die Trackback-Links finden und automatisch in trackbackurl eintragen - das würde die Anzahl der automatischen Trackbacks erhöhen.

Parsehook für Newsisfree

Für Newsisfree-Feeds im AggregatorTool einen Parsehook aktivieren, der den Link auf den Originallink auflöst.

Beim MetaweblogAPI und beim BloggerAPI kann eine Blogid übergeben werden. Im Moment ist das immer 'weblog', das ist ja auch das einzige Tool, das diese beiden unterstützt. Aber wenn ich das Posting rausfaktorisiere, dann kann ich auch in die Stories, ins Wiki oder in die Blogmarks posten, in dem in der blogId einfach der Toolname steht und diese Tools die nötigen Grundfunktionen implementieren, um RSS Items zu posten!

Nötig ist dazu nur eine postRSSItem Methode und eine editRSSItem Methode, sowie die passenden getCategories etc. Methoden (in den stories und im wiki wird das halt auf leere Liste gelegt)

Kategorien sollten hierarchisch gruppiert werden. Bei Selektion von Artikeln nach Kategorie sollten auch alle Artikel aus Unterkategorien geliefert werden. Das Archiv sollte die Form der Hierarchie wiederspiegeln.

Problem: wie stelle ich Kategorien im Weblog-Editor dar? Wie editiert man hierarchische Daten effizient mit dem Webbrowser und wie selektiert man effizient aus einer Hierarchie in einem Webbrowser?

Besonderheit: es müssen mehrere Kategorien pro Posting zuordnenbar sein, evtl. könnte das mit einer inline Multiselektion (also mehrere Zeilen zeigen und durch alle kategorien scrollen) gelöst werden, aber die Checkboxen sind wesentlich effizienter.

Sobald PyCS ein API zum Lesen und Setzen von Optionen hat, sollte PyDS dazu das GUI liefern.

Zusätzlich zu den vorhandenen APIs noch eine Server-Implementierung des MoveableType API erstellen, da dieses API leistungsfähiger ist und besser spezifiziert ist.

Die Seiten im WikiTool sollten über das vpwiki API erreichbar sein, damit man mit VoodooPad mit dem Tool arbeiten kann, so wie man mit ecto mit dem weblog arbeiten kann.

Als bessere Alternative zum PictureTool sollte es ein MediaTool geben. Dieses verwaltet beliebige Mediendateien, die per Shortcut-Syntax eingebaut werden können - dabei erzeugen sie dann immer das richtige HTML. MediaTool sollte durch *Media.py Module erweiterbar sein, so das man z.B. PictureMedia, VideoMedia, SoundMedia haben kann.

Zusätzlich hierfür dann noch das MetaWeblogAPI um die Funktion newMediaObject erweitern, die ihren Upload in dieses Tool einstellt.

Beim Resync sollte immer der Update auf den Server erfolgen, evtl. kann man die bezogen auf die eigene Datenbank unveränderten Postings einfach sammeln und dann in 20er Blöcken abschicken. Der Grund ist, das bei Bugs evtl. der lokale Mirror eingetragen ist, aber nicht der remote Mirror (ähnliches mache ich ja beim ArchiveMirror auch schon so).

- Key ist tool+method (also index_html oder upstream_panel)

- Hilf ein einem Popupfenster

- Hilfeinhalt in reST geschrieben

- Sprachversionen der Hilfeseiten

- defaultsprache Englisch

- Suchfunktion auf die Hilfe

- Rueckverweis von der Hilfeseite auf die zugehoerige URL?

Wenn ein Stray Link ein einzelnes Wort ist und dieser Stray Link nicht gegen ein lokales Werkzeug aufgeloest werden kann, dann sollte er bei der Wikipedia getestet werden, ob dort ein entsprechendes Dokument vorliegt. Wenn ja, dann sollte auf die Seite bei der Wikipedia (evtl. mit konfigurierbarem Template fuer die URL wegen de.wikipedia.org) verwiesen werden anstelle auf die 404.html im lokalen Wiki.

Wenn der XSS aktiv ist (oder später auch wenn Kommentare über XSS in einen FTP-Driver eingemischt werden), kann mittels wfw:comment und wfw:commentRSS auf die Kommentarseiten hingewiesen werden (sowohl auf die HTML-Seite als auch auf die RSS-Seite). Damit könnten Aggregatoren automatisch die Kommentare hinzumischen zu den Feeds!

Wichtig dafür ist allerdings, das im PyCS auch noch Unterstützung für das Comment API rein kommt, da das sonst keinen Sinn macht!

Ein Beispiel für diese Technik ist im Bitworking-Feed zu sehen: http://bitworking.org/index.rss

Ähnlich wie bei Kategorien sollte es ein Feld geben in das man neue Kategorienamen eingeben kann, die dann normalisiert und auf ITE angelegt werden und gleich auch als Topics für das eigene Weblog aktiviert werden. Dabei nachprüfen, ob das Topic evtl. schon existiert und in dem Fall nur aktivieren, nicht anlegen.

Sehr viele können direkt raus. Andere können reduziert werden: die Feedreparatur (wo Link und Title repariert werden) und das gleiche bei den Items kann raus und durch korrektes Setzen der entsprechenden Felder ersetzt werden. Dann braucht die channellist nicht mehr locken. Die itemlist locked wegen dem Newstatus, evtl. könnte man das einfach durch Funktionen in den Hintergrund legen: eine Funktion, die eine Liste von IDs bekommt und diese Items auf gelesen setzt, die dann in den Hintergrund gestellt wird.

Feedupdates sollten auch erst gesammelt werden und dann jeder Feed einzeln in den Hintergrund gestellt werden, jedenfalls wenn in der Oberfläche auf aktualisieren geklickt wird sollte das im Hintergrund geschehen. Die Erstaufnahme sollte weiter im Vordergrund sein.

Dazu musss der Aggregator auch seine Queue benutzen, derzeit benutzt er die nicht. Den Feedcheck könnte ich durch einen automatisch angelegten Timer ersetzen, der braucht nicht alle 10 Sekunden losrappeln, da reichen alle 10 Minuten.

Seiten sollten runtergeladen und als eigene Files gespeichert und verlinkt werden. Dadurch sind sie auch nach Verschwinden der originalen Seite noch verfügbar. Caching sollte nur beim Anlegen des Blogmarks und beim Refresh aktualisiert werden.

Massenbestellungen aus einem OPML-File ermöglichen, damit das einfacher geht - z.B. wenn der Aggregator mal wieder bei Jutta einen Knoten in der Datenbank hat.

Der Feedparser ist jetzt nicht mehr unter GPL-only, daher kann er integriert werden. Beide Parser sollten als Option am Feed wählbar sein (default in den Einstellungen wählbar), so das man auch noch meinen alten Parser nutzen kann, da dieser in manchen Fällen toleranter ist. Ausserdem unterstützt der feedparser auch Atom feeds.

Lokale Seiten sollten gecached werden, damit die Anzeige schneller erfolgt. Das MeshTool sollte eigentlich alle Features liefern die einen intelligenten Update ermöglichen. Wird ja bei der Cloud jetzt schon so gemacht.

Der Aggregator sollte Feeds vorgeschlagen bekommen. Diese sollten sich aus dem Community Server ergeben. Eventuell ähnlich wie das bei Radio passiert, nur das die Benutzer-ID entsprechend eingesetzt wird: damit nämlich die Kommentarfeeds und Trackback-feeds automatisch angeboten werden, so das User nichts von den Kommentaren verpassen. Eventuell in die Capabilities aufnehmen und daraus Feeds im Aggregator konstruieren. Aber was ist, wenn der Benutzer diese Feeds löscht?

Lösungsansatz: die Feeds eintragen, wenn noch keine Feeds drin sind, also wenn die Liste leer ist. Wenn der Benutzer schon Feeds angelegt hat, dann werden die nicht automatisch angelegt und können gelöscht werden.

Von der Statusseite bessere Links in die Detailseiten und Übersichtsseiten von anderen Tools (speziell EventTool, DownstreamTool und UpstreamTool) setzen. Dadurch kommt man vom Status schneller zu den Details. Auch die Informationen erweitern (z.B. Teile aus dem UpstreamTool schon im StatusTool verraten).

Kommentare und Trackback sollten als optionale Overrides über Module konfiguriert werden, um andere Kommentarserver nutzen zu können (oder überhaupt Kommentare, wenn z.B. FTP oder LFS aktiviert sind).

An Stories ein Flag einführen mit dem man Kommentare an/abschalten kann. Dito für Trackback. Grund: manche Stories sollen vielleicht doch mit Feedback versehen werden (Dokus etc.), andere nicht.

Evtl. generell auch an Beiträgen diese Checkboxen vorsehen, dort mit default "ja" (bzw. Default von den Preferences übernehmen!), so das man auch an Beiträgen das ganze steuern kann?

Weblogkategorien sollten auch ohne Weblog-Rendering möglich sein. Damit man auch Pseudo-Kategorien einrichten kann, die nur als RSS-Feeds existieren oder nur für Hooks in Texten (sowas wie Juttas contax-users aktuelle Nachrichten) dienen. Rendering sollte getrennt nach RSS und HTML konfigurierbar sein.

Beiträge mit Trackback durch ein Flag kennzeichnen, damit sie nicht hochgeladen werden (also im Prinzip vom Rendering ausschliessen). Damit diese Trackbacks nicht mehr auf dem Server auftauchen.

Dazu dann aber einen Weg schaffen, mit dem man alte Beiträge finden kann, die z.B. durch ein Rerendering fehlerhaft wurden. Muss ich noch mal drüber schlafen ...

Im Aggregator sollte man einem Newsfeed eine Weblogkategorie zuordnen können, in die neue Postings automatisch reinlaufen sollen. Damit kann man ein Multiuser-Weblog aufbauen, in ähnlicher Form wie das Multiauthor-Weblog-Tool von Radio Userland.

Wichtig: das automatische Posting sollte auf Basis von Regeln erfolgen, so das man einschränken kann, welche Beiträge automatisch gepostet werden. Eventuell kann das ganze generell parallel zum Aggregator realisiert werden: Hooks in den Aggregator, die bei neuen Postings aufgerufen werden, und Regeln, die aufgrund von Matches gegen Elemente der neuen Postings dann ein Posting generieren.

Wenn ein Benutzer remote eingelogged ist, sollte seine ID als Kürzel an Beiträgen gespeichert werden. Damit kann man dann mittels eines zentral installierten PyDS ein Weblogsystem analog zu Moveable Type realisieren - Gemeinschaftsblogs, die nur zentral laufen. Dazu fehlt allerdings noch die Möglichkeit ein einzelnes Tool nachträglich (per Config) von Adminrechten zu befreien - denn sonst müsste jeder als Admin eingetragen werden. Oder macht es mehr Sinn drei Level zu haben? Ich denke nicht. Vielleicht bei den Adminrechten ähnlich vorgehen wie beim Registrierungslevel: wenn der vorbelegt ist, wird das übernommen, sonst wird der Default genommen!

Damit könnte man per Timer (und gesteuert vom UpstreamTool manuell?) einen Refresh bei Tools auslösen, die das unterstützen. Beim UpstreamTool einfach zwei Checkboxen vor jedes Tool und dann _refresh oder _rerender aufrufen.

_refresh kann dann die internen Caches für Content aktualisieren, wie sie im StoryTool und im WeblogTool benutzt werden.

Das ExportImportTool soll mit Hilfe von Callbacks und dem _backup Format Datenexporte erstellen, die in einem eigenen Bereich gelistet werden. Bei diesen Datenexporten soll es sich um Libraries handeln - Makrolibraries, Nuggetlibraries, Shortcutlibraries wären die ersten.

Dazu muss man im Exporttool einen Eintrag für das Tool und für die Bedingungen der Auswahl machen (manuelle Selektion von Elementen - also manuelle Checkliste von Makros, Nuggets etc.). Dieser Export kriegt dann einen Namen und enthält im _backup Format alle selektierten Einträge.

Der Import holt einen aus dem Netz selektierten Eintrag und mischt den in die Datenbestände ein. Dazu sollte das ExportImportTool nachhalten welche Einträge aus dem Import kommen. Der Import sollte ähnlich einem RSS-Feed abonniert werden und zyklisch aktualisiert werden - damit neue Elemente im Export auch bei allen Importern herangezogen werden.

Im Prinzip sowas wie Datenbank-Publish/Subscribe für den Python Desktop Server.

Das Format der Library könnte OPML sein?

Formularbearbeitung in PyDS soll möglich werden. Dazu braucht es zwei Tools:

Das FormTool ermöglicht die Erstellung von Formularen. Diese verweisen auf ein Systemmodul im Communityserver, welches alle Formularfelder einsammelt und als Struct-Objekt an einen authentifizierten RSS Data (RSS + XMLRPC encodierte Daten) Feed anhängt. Pro Formular wird automatisch ein RSS Data Feed geführt. Formulare könnten eventuell auch per ExportImportTool verteilbar werden, wenn es das mal gibt.

Das DataAggregatorTool arbeitet wie der normale Aggregator (einfach die Funktionen und Klassen von dort mitnutzen?), allerdings werden die Datenanteile der RSS Data Feeds gesammelt und als Blobs (pickle) in eigenen Feldern an den Items gehalten. Eventuell kann ich den normalen Aggregator auch nur dafür erweitern, aber die Feeds sollten in einem eigenen Overview stehen (da sie ja in der Regel anders abgearbeitet werden). Andere Tools sollen dann die Möglichkeit haben, aus diesen Feeds Datenblobs zu holen und diese zu verarbeiten. Dazu sollte ich Hooks anbieten, mit denen diese Tools sich im Batch über alle Items einens Feeds hermachen können, oder einen Button mit dem Feed registrieren können, der dann die eigentliche Verarbeitung pro Item aktiviert.

Modellszenario könnte zum Beispiel ein einfacher Shop sein, der dann z.B. die Bestellungen abholt und per GevisTool an die Warenwirtschaft weiterreicht.

Ein Werkzeug mit dem ich FOAF-Daten eingeben kann und dann daraus ein FOAF-File generiert wird, sowie die Standardlinks mit Icon auf mein FOAF-File. Damit würde dieses Format stärker promoted und man könnte eine ganze Menge mehr dokumentieren - der Weg zur digitalen Identität (im sozialen Sinne, nicht im technischen Sinne!). Könnte witzig sein.

Eintragungen von anderen FOAF-Files sollten auch verwaltet werden und dann über knows oder ähnliche Relationen verknüpft werden.

Der Communityserver sollte jedem Kommentar eine GUID verpassen. Und in den Capabilities mitteilen, wenn er Kommentarlöschung erlaubt. Wenn das der Fall ist, soll es eine Funktion deleteComment(usernum, postid, commentid) geben, mit der Kommentare gelöscht werden können. Zusätzlich sollte es einen eigenen Namespace geben, mit dem diese Tatsache mitgeteilt werden kann (pycs: Namespace, und daran ein Element delete, das an Items steht, und die ID im Format usernum:postid:commentid enthält?)

Im Aggregator dann bei Items, die aus dem Kommentarfeed kommen und dieses pycs:delete Element enthalten, einen Button anzeigen, mit dem dieser Kommentar gelöscht werden kann. Könnte bei Kommentarspam helfen.

Erweiterung: PyCS kann auch einfach das MetaWeblogAPI implementieren, für die beiden Standardfeeds die ein User hat (Kommentare und Trackback). Dann kann man dieses benutzen, um Kommentare oder Trackbacks zu löschen und das pycs:-Element sollte besser pycs:item sein, mit der entsprechenden ID des Postings, damit dann mittels der normalen Funktionen auch Edits auf Kommentare und Trackbacks möglich sind. Damit können auch andere PyCS-Nutzer dieses Feature verwenden, auch wenn sie keinen PyDS haben!

Implementierung der Client-Seite des Pingback Protokolls auf der angegebenen URL, so das automatisch bei Kommentaren ein pingback erfolgt. Im Prinzip so wie das Tool für Radio. Zusätzlich im Communityserver auch die andere Richtung implementieren, so das man Pingbacks einsammeln kann, genauso wie man heute schon Trackbacks und Kommentare einsammeln kann.