Slideshow starten

MoinMoin!

Software-Entwicklung beim MoinMoin-Projekt

Technologie-Ausblick MoinMoin 1.9 und 2.0

TechTalk beim DLR 2009-09-08 15:00.

Vortragende:

• Reimar Bauer
• Thomas Waldmann

MoinMoin

• Wiki-Software
• Python powered
• Freie Software unter GPL
• beliebt für Internet und Intranet
• Communities, Projekte, Firmen, Organisationen
• CMS-artige Anwendung

Team / Community

• kleines Kern-Team von Entwicklern
• Beiträge von Wiki-Anwendern:
  • Fixes
  • Features (Patches oder Plugins)

  • Übersetzungen (CheckTranslation)

  • Doku (http://master19.moinmo.in)

• Entwickler oft aus Deutschland / Europa. (Acknowledgements)

• Internationale Community.

Motivation

• oft als Freizeitprojekt aus Spass am Python-Programmieren
• ab und zu kommerzielle Entwicklungen (i.d.R. GPL)

• ab und zu Sponsoring (z.B. GSOC, GHOP, u.ä.)

• Studien/Diplomarbeiten
• Entwicklungen von Anwendern aus Eigenbedarf
  • privat
  • Organisationen / Firmen

Team-Kommunikation

• IRC: schnell MoinMoinChat IRC-Logs im Wiki

  • #moin für Support, #moin-dev für Entwicklung

  • CIA benachrichtigt über commits via IRC Channel

• Wiki: mittel-schnell
  • Planung, Dokumentation
  • Bug-Tracking, Support
• Mailingliste: langsam
  • Support, Announcements
• Voice-Chat mit Mumble (nach Absprache)

Entwicklungstools

• Mercurial DVCS zur dezentralen Entwicklung, aber mit zentralen Haupt-Repos
• Code-Review:
  • vor Commit oft via pastebin: paste.pocoo.org

  • nach Commit via Web-Oberfläche von Mercurial

• IDEs: jeder Entwickler benutzt das, was ihm gefällt (vim, mc, Eclipse, ...)
• py.test: Unit-Tests / Style-Tests PEP8
• Coverage-Analyse

• Docs: http://docs.moinmo.in/

Repos / Releases

• "devel/experimental" [2.0-*]
  • größere Änderungen zunächst separat entwickeln
• "next" [1.9]
  • nächste Release
• "stable" [1.8]
  • nach Release primär Bugfixes, kleinere Features
• "oldstable" [1.7]
  • vorhergehende Release: Security-Fixes
• "extensions" [1.7 - 1.9]
  • größere Plugins oder Fallstudien

Release 1.9 (2009)

• Pygments Sourcecode-Highlighter
• svg drawings
• Xapian-Suche via xappy
  • vorher: xapwrap (3rd party, unmaintained)

• LanguageSetup / CheckTranslation / i18n page sets

• Installations-Dokumentation überarbeitet
• OpenID: Support for Teams extension.

• Python >= 2.4

1.9: Moin == WSGI-Applikation

• Deployment aus Sicht von Moin immer gleich
• leichter zu entwickeln / debuggen / supporten / pflegen
• Werkzeug als WSGI-Library
• non-WSGI-Support via Flup (liegt bei)
• oder via jeden anderen WSGI-Adapter
• Static File Server eingebaut (CSS, Images, JS)
• Apache: mod-wsgi benutzen (auch mit 1.8.x)!

1.9: Groups/Dicts Code Rewrite

• modulare Backends
• Zugriff auf Group/Dictionary-Definitionen in:
  • Wiki-Seiten (wie seither)

  • Wiki-Konfiguration (neu)

  • Kombination von Backends

  • LazyGroupsBackend als Vorlage für weitere, z.B. ldap

• weniger Cache-Konsistenz-Probleme

Release 2.0 (2010/2011?)

• viele Code-Teile neu geschrieben
  • einfacher
  • mächtiger
  • derzeit: Großbaustelle!
• API: inkompatible Änderungen am Core-Code

• Python >= 2.5

2.0: Storage API Items

• Item (1.x: Page oder Attachment):
  • kann Meta-Daten haben
  • kann Revisionen haben
• Revision:
  • hat Meta-Daten (mimetype, ACLs, history, ...)
  • hat Daten
• Meta-Daten: dict-like, beliebige Strings als key/value-Paare
• Daten: file-like, binary

2.0: Storage API Items

2.0: Storage API Backends

• Backend:
  • speichert eine Menge von Items
  • Auflisten von Items
  • Zugriff auf Items
  • globale History
• Middleware:
  • wie Backend, speichert aber nichts selbst

2.0: Storage API Backends

• fs19 (Daten-Import von moin 1.9)
• fs (neugeschriebenes Filesystem-Backend)
• hg (Mercurial DVCS)
• SQLalchemy: sqlite, mysql, postgresql
• fileserver (Ordner/Datei-Freigabe/Zugriff)
• memory (RAM, nur für Tests u.ä.)
• flatfile (unrevisioniert, einfache Dateien)

2.0: Storage Middleware: ACLs

• erhöht Sicherheit (ACL-Checks nicht mehr manuell, sondern automatisch)
• 2.0 ACL-Capabilities: read,write,admin,create,destroy
• create: Erzeugen eines noch nicht existierenden Items
• destroy: Vernichten von kompletten Items oder Item-Revisionen
• 1.x revert wurde abgeschafft (write)
• 1.x delete wurde abgeschafft ("rename nach trash")
• rename capability check == src:read,write dst:create,write

2.0: Storage Middleware: Router

• ähnlich mount/fstab
• normale Inhalte unter /
• Userprofile unter /UserProfiles/
• Mülleimer unter /Trash/
• denkbar: /Talk/, /User/, ...
• i.d.R. ist das jeweils ein Storage-Backend, das von einem passenden Satz ACLs geschützt wird
• create_simple_mapping() als Helfer

2.0: Storage API Layers

1.x: In-Place löschen

• gelöscht == aktuelle Revision ist nicht vorhanden
  • exists-Check langsam, daher auch:
  • Link-Rendering langsam (blau vs. grau)
  • Storage müllt sich mit gelöschten Seiten zu
  • Rename mit Ziel == gelöschte Seite geht nicht

2.0: Müll-Entsorgung

• gelöscht == befindet sich unter Trash/*
  • kein Rename-Problem
  • Content-Backend bleibt sauber / schnell
  • exists-Check ist schneller

  • destroy Trash/* -> endgültig weg

2.0: XML-Serialisierung

• sax-basierte OO-Implementierung, auch von unserialize
• serialize(xmlfile, obj)
• unserialize(xmlfile, obj)
• obj: backend, item, revision, ...
• Anwendungen:
  • backup/restore
  • item packages (TODO)
  • wikisync (TODO)

2.0: Item OO-UI

• UI / Rendering passt sich dem mimetype des Items an
• Hierarchie von UI-Klassen, möglichst viel wird in den allgemeinen Klassen implementiert:
  • z.B. funktioniert delete,rename,history,revert,download,upload genauso für Binary items wie für Text items

  • oder verkleinern/drehen/spiegeln tut für mehrere TransformableImage Unterklassen (gif,png,jpg)

  • ebenso wird der Text-Editor für alles text/* benutzt
  • show oder diff für Text ist aber anders als für Image

2.0: show vs. get

• action=show wurde zu do=show (default)

• Link auf "show":

  • altes und neues Markup: [[foo]]

  • text/moin-wiki: Wiki-Seite rendern und im Content-Bereich des Themes darstellen
  • application/zip: ZIP-Listing generieren und im Content-Bereich des Themes darstellen

2.0: show vs. get

• action=raw wurde zu do=get (generisch, mit "304 not modified"-Unterstützung)

• Link auf "get":

  • alt: [[foo|...|&action=raw]]
    bzw. [[attachment:foo|...|&do=get]]

  • neu: [[foo|...|&do=get]]
    bzw. [[/foo|...|&do=get]]

  • text/moin-wiki: Wiki-Markup herunterladen / im Browser darstellen (ohne Theme)
  • application/zip: ZIP-Datei herunterladen

2.0: SVG-Support

• kompatibel per Google's svgweb
  • Internet Explorer (mit Flash-Plugin 9+)
  • andere Browser auch mit nativem Renderer
• SVG items
  • .svg-Output von svgwikidraw (nicht .png)
  • Bilder, Charts, Animationen, ...
• Security?
  • unsafe SVG
  • safe SVG Parser (TODO)

2.0 TODO

• Vorsicht Baustelle:
  • derzeit nur für Entwickler / Geeks geeignet
• wir suchen Python-Entwickler, die uns helfen!
• diverse große Änderungen fehlen noch komplett, sollten aber für 2.0 gemacht werden
• vieles tut nicht mehr wegen den großen Änderungen am Core
• vieles braucht aus prinzipiellen Gründen nen Rewrite
• das, was schon tut, muss mehr getestet werden

2.0 TODO: Jinja2-Theme

Derzeit wird noch "modernized" (alter Theme-Code) verwendet.

Aber: die Inhalte ("content" div) werden teilweise schon mit Jinja2 generiert.

TODO: Rewrite des alten Theme-Codes für Jinja2.

• Füttern der richtigen Daten in die Template-Engine
• Templates erstellen
• Restrukturieren/rewrite CSS
• Restrukturieren Images

2.0 TODO: Merge DOM-Repo

DOM-Converter ersetzt Parser/Formatter:

• text/moin-wiki -> domtree

• domtree -> html

• TODO: reST, Docbook, Pygments -> domtree

• TODO: (GUI-Editor-)html -> domtree

• TODO: domtree -> moin wiki markup

Vorteile:

• sauberer HTML-Output
• besseres Include/TOC

2.0 TODO: Merge Realtime-Editor

Paralleles Editieren mit Synchronisation in nahezu Echtzeit.

• basiert auf mobwrite
• Server-Komponente integriert in moin

TODO:

• praktische Tests
• Usability?

1.x Plugin-System

Derzeitiges Plugin-System ist zu kompliziert:

• für eine Erweiterung braucht man oft:
  • actions
  • macros
  • parser
  • css, html, js
• Aufteilung unnatürlich
• Anwendung liegt verstreut in div. Directories

2.0 TODO: neues Plugin-System

Neues Plugin-System entwerfen und implementieren:

• konfigurierbare Liste von Plugin-Directories
• 1 Subdirectory pro Erweiterung
  • Code
  • Templates, HTML, CSS, JS, Images, ...
• Erweiterungen registrieren sich selbst
• Folge: alle Plugins anpassen

Links

• http://moinmo.in/

• MoinAPI/Beispiele

• http://docs.moinmo.in/

• http://hg.moinmo.in/

• http://www.ohloh.net/p/moinmoin

• http://cia.vc/stats/project/moin

• http://moinmo.in/MoinMoinTalks/DLR-2009-09-08

Fragen?