MoinMoin 2.0

MoinMoin 2.0 (short: moin2) will be a big step in moin development, we are rewriting / heavily refactoring some core components of moin.

Repo: Currently there are http://hg.moinmo.in/moin/2.0-storage and http://hg.moinmo.in/moin/2.0-storage-dom-bblank/ in use.

Note: See also the Talk at the DLR (text in German, pictures in English).

The big news

Storage API, misc. storage backends

moin 1.x: the storage code was mixed into Page, PageEditor and AttachFile modules (yes, quite messy).

moin 2: storage code will be in MoinMoin.storage package and misc. storage backends will be supported, all conforming to the same "storage API":

• fs - filesystem storage (cdb for index)
• fs2 - filesystem storage (sqlalchemy/sqlite for index/news, hash-addressing for content)
• fs19 - filesystem storage like moin 1.9 (read-only)
  • TODO: more testing of 1.9 to 2.0 migration scenarios, meta-data fine tuning
• SQLalchemy based backend
  • TODO: memory/performance tuning
• hg - mercurial DVCS storage
• flatfile - very simple flat-file storage (only for special applications)
• memory - memory backend (only for special applications, like debugging)

TODO:

• more testing
• indexing of metadata
• searching and listing

Mimetype items

In moin 1.x, there were 3 main types of stored objects in the wiki: pages, attachments and user profiles

In moin 2, there will be only 1 type of stored object: an "Item".

Some facts:

• a storage backend stores named items
• an item may have metadata
• an item may have revisions
• a revision has metadata
• a revision has data
• metadata can be any key: value pair
• data can be of any type (text, binary)

TODO:

• which kind of drawing items we support and how we store them has to be seen (see moin 1.9, svg stuff, twikidraw, anywikidraw, etc.)

Item OO user interface

moin 1.x: pages and attachments had separate user interfaces (deleting a page worked differently than deleting an attachment, uploading an attachment worked differently than uploading page content, pages had revisions, attachments not).

moin 2: unified user interface for items:

• show item (render wiki page, render image/video with some additional data - all done in wiki content area)
• item infos / history
• modify item (create, edit, upload, delete)
• download item content (raw wiki page, raw image)

Page, PageEditor, AttachFile code modules are dead.

TODO:

• move remaining stuff from Page / PageEditor to Item (or whereever it should be).

• UI currently is only for developers, needs much polishing / theming before end user can use it, see themeing.

Code cleanup

Lots of crappy code was deleted.

TODO:

• Not everything was replaced by better code yet.

DOM based transformations

moin 1.x: parse wiki markup line-by-line, create html on the fly (problems: crap html, no xhtml, crap include, crap TOC, ...)

moin 2.0: input -> converter -> DOM tree -> converter -> output

• wiki -> DOM

• creole -> DOM

• pygments -> DOM

• DOM -> html

TODO:

• merge dom repo -> storage repo

• more practical testing of dom code, fix bugs
• add missing stuff
  • smileys

• reST -> DOM

• html -> DOM (for gui editor)

• DOM -> wiki (for gui editor)

• DOM -> reST (for gui editor)

• any -> DOM, DOM -> any

Themeing with Jinja2 templating engine

moin 1.x: Output generation was mostly done by python code with embedded html. Some of this was within pluggable themes, some was hardcoded.

In moin 2, we currently still have the old themeing code that renders the theme header and footer. Optionally, this can be switched to Jinja2 template based theme rendering.

New parts of the code (e.g. actions) that produce "content area" output are already based on jinja2 templates.

TODO:

• we don't have a jinja2 templates for the theme header/footer yet
• we don't have the infrastructure that feeds the templates with the values yet.
• some old code with hardcoded html is still left.
• reorganize / recreate css, icons, ...
• create a template based moin dump.

GUI editor update and different approach

• ckeditor 3.0
• currently just stores html items (either unsafe or safe html)

  • no conversion problems

  • but: no collaboration between gui editor and text editor users on the same item

XML serialization

Can be used to backup / restore content of all storage backends / items.

Possible usage scenarios:

• import from / export to other apps
• package some pages / install page package

TODO:

• more tests
• add xml declaration and other stuff formally needed
• wikisync
• wiki xmlrpc
• replace page package with xml files
  • packagepages, i18n packages
  • interactive export/import for single/multiple pages

new plugin system

The old plugin system is not powerful enough and too complicated.

TBD

wiki xmlrpc

We need a better api there based on generic mimetype items.

TBD

How to help

As you see above, all this is a quite big task and we need help:

• good Python, Javascript, HTML/CSS developers
• people with a good artistic skills and taste for theme development

How to start:

• Talk with us on MoinMoinChat.

• Read and try the new code.
• Expect brokenness/incompleteness and help fixing it.
• Bring in your ideas about how to improve. Some stuff is not specified yet.

Note: Some old content can be still seen here: here