MoinTng

MoinMoin - The Next Generation

Features:

• cvs-Backend (evtl. auch andere)

  • im nächsten Schritt kann man ein Offline-Moin erzeugen, welches ein remote-Repository benutzt
• Unicode
• Templates

• LinuxWiki/MehrSprachigkeit

• XHTML konform
• klare Trennung Parser - Renderer
  • internes Datenformat: XML?
  • Macros können Parser aufrufen (max recursion depth=1)
    • Der Macro-Output sollte auch in einem internen Format erfolgen, der einen Weiterverarbeitung mit den verschiedenene Renderern ermöglicht.
    • genau, das gleiche format, was der parser auch liefert (ob das irgendein python konstrukt oder xml ist, ist eigentlich egal)
  • im nächsten Schritt: alternative Parser

• WikiInfosAlsDownload Diskussion darüber siehe dort

  • Wozu? Wieviele Rechner ohne online-Verbindung habt ihr (oder genauer gesagt: wieviele, die nicht leicht eine Online-Verbindung haben könnten?). Jeder spreche bitte nur für sich und stelle keine vaguen Vermutungen an...

    • ThomasWaldmann: 0

Vom diskutieren kommen wir nicht weiter! diese seite ist eigentlich nur eine zusammenfassung was wir (bastian, thomas und ich) am lulug-stammtisch diskutiert haben, was wiederum nicht viel mehr als eine zusammenfassung der diskussionen im wiki darstellt. -> es ist zeit für taten. -- RonnyBuchmann 2002-10-17 23:44:40

Pro (+) / Contra (-) / Kommentare (!) / Fragen (?):

• ! cvs fügt eine Abhängigkeit hinzu, wo moin gerade auf bestem Weg war, ohne externe Tools auszukommen (aktuell nur "diff", nach difflib-Patch auch kein diff mehr)
  • das haben wir doch schon ausdiskutiert, cvs als eine abhängigkeit zu bezeichnen grenzt an einen witz
    • für Linux ja, für Windows nein

      • was hat das jetzt mit X11 zu tun

• ! cvs ist langsamer (wobei sich das in der Praxis wohl nicht allzu stark auswirkt???)
  • ich glaube nicht, dass das große auswirkungen hat

  • cvs braucht man nur zum speichern und für die history/diffs, man kann ja auch einige cvs funktionen in python nachcoden, z.b. bei RecentChanges

  • cvs speichert backward-patches, also von 1.3 auf 1.2 auf 1.1 - 1.3 ist als volle version vorhanden, dh. die aktuelle revision ist kleinkram und history zeugs ueber 100erte revisions wird man eher mal nicht 100ert mal am tag machen wollen, oder?
• + Offline-Version wäre preiswerter für fleissige Schreiber ohne Flatrate
• ! Machbarkeit Offline-Version ist fraglich. Während ein fleissiger Schreiber offline editiert, kann ein anderer fleissiger Schreiber on- oder offline Strukturen (nicht nur Inhalte) massiv ändern, so dass ein sinnvoller Merge unmöglich wird oder einfach Mist beim Merge rauskommt - wie will man da sicherstellen, dass keine Informationen und Teil-Strukturen verlorengehen?
  • der unterschied zu online-änderungen ist nicht so groß, und informationen gehen generell nicht "verloren"
    • durch die conflict-merge funktion vom cvs dürfte es sogar besser gehen als jetzt
      • wenn ich ne Seite online umbenenne/lösche, während du offine dran editierst, was dann?

        • dazu ist der Ansatz mit XML gernicht schlacht. Hier kann man Metadaten mit in die Struktur aufnehmen, die solche Informationsverluste verhindern bzw. umgehen!

          • xml ist nur die interne verarbeitung (evtl), nicht das ablageformat!
      • seiten umbennenen gibt es nicht und löschen auch nicht! es gibt nur ändern, und da funktionierts
• ! Unicode wäre natürlich super, macht aber eigentlich nur nach einem Konzept für Mehrsprachigkeit wirklich Sinn (es ist ja auch jetzt schon möglich Moin mit anderen Zeichensätzen, wie z.B. koreanisch, zu betreiben), denn erst dann braucht man wirklich Unicode
• ? Funktioniert cvs und Unicode? Funktioniert regex mit Unicode?
  • cvs: solange man nur einen zeichensatz benutzt (utf-8) dürfte es keine probleme geben
    • ? bringt das dann noch was?
      • laut bastian ja, utf-8 deckt wohl alles ab
  • regex: das tut (auch mit python?)
    • Wenn es sich bei den Locales bediehnt, wie z.b. Perl, dann macht das auch keinen Unterschied mehr.
• ? was soll XML als internes Datenformat bringen? Verarbeitungsgeschwindigkeit?
  • mit internes Datenformat habe ich gemeint, was der parser erzeugt
  • daraus kann man dann x-beliebige ausgabeformate erzeugen
  • meine Idee war nicht unbedingt, XML zu erzeugen sondern für die interne Darstellung einen DOM-artigen Tree zu benutzen. Die XML generierung ist dann eine Kleinigkeit.

• ! ich finde die Einfachheit von Wiki / MoinMoin ein sehr schönes Feature - auch die im Backend mit dem direkten Speichern des eingegebenen Seiteninhalts in einer Datei, die den Seitennamen trägt. Diese geht mit den Vorschlägen verloren.

  • der seitenname bleibt weiterhin der dateiname (es sei denn mehrsprachigkeit führt zu einer anderen lösung)
    • ich habe den Eindruck, viele wissen nicht, warum es XML gibt. Mehrsprachigkeit könnte man ja auch so machen, dass man als Massenspeicher-Format tatsächlich XML einsetzt, dann kann man auch ohne Aufwand Mehrspachigkeit in einer Datei realisieren! Es wird zwar nicht ganz so schnell sein, wie ein proprietäres Format, aber ich denke, man merkt es nicht. Und XSLT-Transformationen sind auch schon sehr effizient.
      • das würde ziemlich viel eigenen Code erfordern, denn "diff" kannst dann nimmer verwenden, wenn Du alles zusammen wirfst, ebensowenig Timestamps auf den Dateien u.v.a.
        • klar kann ich das nimmer verwenden, aber es gibt ja solche Operationen auch auf XML, und teilweise viel mächtigere als diff und co.
• - ich finde Templates "over-engineered", denn das geniale am Wiki ist der super-schnelle Seitenaufbau. Der würde etwas langsamer von statten gehen. Was das Wiki jetzt schon kann ist paradiesisch.
  • Immer eine Frage der Implementierung.
  • templates für die header/footer, für alles andere reicht css
    • ? wo siehst du denn da einen vorteil?
      • schau dir mal wiki.fresco.org an, das ist moinmoin und passt trotzdem ziemlich gut (mit ein paar gotchas) in den rest der site (www2.fresco.org, issues.fresco.org)

Generell: wäre das nicht eher was für Diskussion im MoinMoin-Wiki?

• worüber haben wir gestern gesprochen...
  • trotzdem kannst Du ja erstmal mit dem Autor drüber reden

Nochmal generell: ich würde sagen, ein MoinMoin mit diesen Features zu bauen wäre Vergewaltigung des Sourcecode. Ich würde da eher zu ner Neuentwicklung tendieren, bei der man höchstens ein paar Module aus MoinMoin wiederverwendet. (ich kenne den MoinMoin Sourcecode nicht!). Aber prinzipiell hört sich XML and so on gut an. Man kann das dann sehr einfach durch XSLT in jedes beliebige andere Format konvertieren. Vielleicht kann man sich sogar Ansätze überlegen, die verlinkte Struktur im Wiki in eine lineare Form zu transformieren, so dass man z.B. das Wissen eines Wiki in einem PDF Speichern kann! -- JanRoehrich 2002-10-17 13:57:38

• genau darum geht es, es sollte nur in teilen kompatibel sein

• Zur Diskussion "Wissen eines Wiki speichern": siehe WikiInfosAlsDownload