Speaker notes for Umeet online IRC conference at 2005-12-xx 19:00UTC.

Welcome

Welcome to the "MoinMoin 1.5 and beyond" talk.

A wiki engine is a software to run a wiki server (the server doesn't need not be big, a notebook running moin is also a server in that context).

The talk will begin with some short wiki intro, talk about the new features in moin 1.5 and give some ideas about where moin development is heading for future versions.

If there is time and interest, we can add some generic wiki questions or development topics at the end of the talk.

If you have direct questions about some talk topic, please use channel #qc and ask immediately, especially if I start talking chinese for you.

Same if I am going too fast or slow.

Short wiki intro

I won't bore you with many words about what wiki is, just for the people who don't know yet:

A wiki is a "user editable web site", that usually is used in a very collaborative manner.

The biggest and most famous wiki site nowadays is http://wikipedia.org...

... but wikis are not only used for writing encyclopedias, but for much more.

You can use a wiki for your personal notes, as a knowledge base, as a communication medium, for making documentation and much more.

You can use it privately, as a corporate internet, as an organisation website, as a wordwide place to dump (or restore your brain.

You can use wiki for almost everything you are capable to express in words and arrange by using hyperlinks or reverse links or the built-in search. As wiki is mostly about free-form text, it doesn't restrict you.

What is special about MoinMoin?

There are many wiki engines out there, I think it must be about 100 (and maybe 10 major engines in widespread use).

But MoinMoin (see http://moinmoin.wikiwikiweb.de/) is special because it has some nice properties:

It is Free Software (GPL).

• OK, not THAT special for Linux users, but we get rid of the commercial competition by this point. <g>

It is implemented in Python.

• "Well, who cares...." you might say, so let me get a bit more detailed about this item. Being written in a nice, clean and very-high-level language like Python has a BIG influence on development of the code (fun!) and extensions (it is so easy, many people can write extensions). Unlike PERL (write-only, looks like line noise), you can even READ the code (even if you don't know Python yet). Unlike C/C++, you don't have to care about lowlevel details. And therefore you need MUCH LESS code and get a better overview. Unlike PHP, Python is a GENERIC programming language (== not only suited for web app development). Learning Python is less effort than most other languages. Even if you can already code in some other language, it can be less effort learning Python and using it for some project, than implementing that project in some older lower-level language.

It is modular.

• You can write your own themes, macros, parsers, formatters and plug them into MoinMoin core code. This keeps the core code from getting bloated. (more infos about developing those things at the free-form end of this talk)

It is running fast.

• We did quite some tricks to make page rendering fast ( -> they get compiled into python bytecode), making the static parts fast, while keeping the dynamic parts dynamic.

It is developping fast.

• Because we use Python.

If you want a quick course about MoinMoin usage, see http://moinmaster.wikiwikiweb.de/WikiCourse.

If you want to play, please use the http://moinmaster.wikiwikiweb.de/WikiSandBox there.

Maybe bookmark those links and try them later. If you edit all at once now, you will see quite some edit conflicts.

MoinMoin 1.5 news

In the pending 1.5 release (expected to get released in late December 2005), we will add some nice new features:

GUI WYSIWYG editor

For us geeks, this is not that important, we will maybe rather continue to use the simple textarea editor. But for most people (== non-geeks), this is a very important feature - because it will be easier to use for them.

We just used http://fckeditor.net/ for that (also Free Software).

FCKeditor uses a HTML-editing control built-in in some current browsers (Mozilla, Firefox, Netscape, MSIE). Opera and Safari might be supported soon.

The hard part of that job was (and is) to convert the HTML the editor creates back to wiki markup (we also could have stored the raw HTML, but that's not the wiki way). And guess what!? Every browser creates slightly different HTML of course. And every browser has different bugs and limitations...

Better wiki farm support

If you run a wiki for a large organisation, you have some special needs.

You can now use a common user directory for all wikis in a wiki farm, so the users need one profile only.

You can add your already existing authentication scheme to moin (in a modular way) and have single-sign-on and create user profiles automatically. Currently supported: HTTP basic auth, SSL client certificates, PHP SSO, external cookies.

Possible: database, LDAP, ... (you can easily write your own function)

For supporting this modular auth, moin does simply use a list of auth methods now, calling one after the other.

You can have a separate "user home wiki". If you have 1000 users, you don't want to have 1000 user homepages in the same namespace as your real content.

Alternatively a user can decide not to have a homepage, but to just publish his email address on RecentChanges instead. But: better don't do that on a public wiki running on the internet.

Better navigation

If you run a whole bunch of wikis in a farm, navigation is also an important issue. The user should always know where he is.

This is why we added an optional interwiki name display in the header area and also a clickable MainPage / SubPage display you can use to directly get at the upper page level. These "location breadcrumbs" ("where am I?") complete the "path breadcrumbs" ("how did I get here?) we had for long.

Giving users limited admin rights

The autoadmin SecurityPolicy makes it possible now to give users limited admin rights, e.g. on their homepage and subpages and on some group pages. So they can hide some private pages or have read-only pages without needing the wiki admin all the time.

Other changes

We also did quite some cleanup and bug fixes and other smaller features, of course. The CHANGES file in the distribution archive lists them all (hopefully :).

BTW: we require Python 2.3 now.

• No, we didn't do this to annoy Python 2.2 users, but to deliver better tested code (our developers just don't use Python 2.2 any more and incompatibilities already crept in into some 1.3.x releases, so we better stopped supporting 2.2 and using some 2.3 features).

Python 2.3/2.4 is easy to install from source, even if you have some old "don't touch" Linux production box.

Wanna help testing?

1.5 is currently in late beta stage. We will have some release candidates soon and a release in december 2005. We are a bit late already, so rather expect late december.

If you're curious and want it now, you can use beta6 (or soon rc1) version (we use it ourselves for the moinmoin and moinmaster main sites). Everything that was there in 1.3.x should also work in 1.5 beta, we only need to do some work on the new features, especially on the GUI editor.

If you're still running some old MoinMoin (< 1.3.x), we recommend that you first upgrade to 1.3.5 (or 1.3.4). Two small steps might be easier for you than one big step.

Beyond 1.5

Predicting the future isn't easy, but I can at least tell you some more or less vague ideas of what's planned:

After 1.5 release, we want to concentrate on development of moin 2.0 and especially following things:

Generalize the currently differently implemented pages and attachments to generic "mimetype items":

• a wiki page will just get an item of type text/x-moin-wiki
• an attached PNG image will just get an item of type image/png

This way we will get rid of the rather ugly AttachFile code, the special markup needed for attachments, we will have revisions and ACLs automatically for everything, and as you can up/download a file, you will also be able to up/download a page text. And we will use nice OO code for implementing it, including the obvious inheritance of mimetypes.

For binary items, we can't continue storing ACLs *IN* the item (like we currently just place the ACL onto the wiki page), so we will split off ACLs and store them separately. Same for storage of mimetype and other item metadata.

As we have to change the item storage anyway (again), we will also make some storage backend module. We will implement it as a file system storage, but we try to do it generic enough so that it is possible to do database storage or to use a version control system for storage alternatively.

Another change we plan is link and include markup - currently it is just too complicated and too special and when we have generalized items, we can also have generalized "link to" and "include" markup.

BTW, if you look at mimetype items and include operation, some other goal gets visible: wouldn't it be nice to visually include any other mimetype item on a wiki page? For some stuff, this is easy (and already done, like images or text/* mimetypes), for other stuff, this gets more complicated (like pdf, LaTeX, other document formats). Maybe we first should work on having some DOM-like internal item representation before doing that. This could take a while (and won't be in 2.0).

OK, so far for now, you see we have enough work for the next years. You can help us reaching our goals faster and/or better by contributing ideas, plans, code, css, documentation and translations.

Our main coordination medium is the MoinMoin wiki site and IRC channel #moin on irc.freenode.net.

Questions / free talk

OK, that was the prepared part of my talk. Feel free to ask more questions about the talk.

...

Feel free if you have other questions about wiki, usage, installation, ...

...

I can also talk a bit about MoinMoin development specific topics if there is interest, raise your voice now if interested.

For example:

• how you can use macros, actions, parsers, themes to extend moin
• how you can contribute code or join moin development team
• why we use GNU arch now (and maybe bzr or hg soon) as our version control system

...

OK, thanks for listening and see you on http://moinmo.in/ !