[Moin-user] MoinMoin Questions

Thomas Waldmann tw-public at gmx.de
Fri May 23 19:24:13 EDT 2008


Hi Keith,

> 1.  One of the features I like is that I can produce docbook from MM
> mark-up.

Please note that docbook stuff is still being developped/improved.
1.7 will have a better docbook formatter than previous versions.

> Suppose I'd like to generate a PDF of a Wiki at some
> point in the *past* --- is there a straightforward way to do this?

Not AFAIK. If you can code in Python, I think it's doable, though.

We need more developers caring for docbook stuff anyway, so feel
welcome! :)

> BTW:  I believe I already know that attachments don't have
> any history,

Right. Not yet. We are working on it.

> 2.  Is there an external mechanism for locking the MM repository?  My
> back-up solution would probably include LVM, so I just need a method
> to momentarily lock the repo until a snapshot is setup.

No. But you could stop and restart moin, if you very much need to play
safe.

Otherwise you could also snapshot while having it running, should work
mostly.

> 3.  (And this is the BIG ONE) Two of my projects are going to be VERY
> media intensive.  Lots of scanned documents, photos, videos and audio.

I have recently improved support for big files (will be in 1.6.4 and
1.7.0). "Big" in that context means stuff >>10MB (like ISO CD/DVD
images, movies, but not photos or audio usually).

> So one thing I would REALLY like is a generic media database connected
> to the WiKi in some way.

Nothing there yet. What we will do with attachments is to unify them
with pages, so everything is just some (revisioned) item with a
mimetype. Hopefully in 1.8, but please don't hold your breath. :)

> One solution might be to create pages based on some type of domain
> centric grouping (dates, content, media type,...) and have the media
> elements attached to this page.  The actual page "text" would be treated
> as a free form database (I'm thinking SMTP header-line like formats,
> this would require a Parser plugin?

Yes, sounds like a Parser.

BTW, when we finally have the new backend (see above), some of that
stuff could maybe go into metadata of the media item (which will be key:
value also).

> My understanding is that either would require some sort of MM plugin
> that allows linking to individual media elements from other MM pages.

If you store stuff externally at some URL, you can always use interwiki
to have comfortable linking from moin, e.g.:

Media:pictures/foo.jpg

and in the interwiki map:

Media http://server/media/

> It would also support searching and sorting.

moin has a slow builtin search for page content and a fast xapian based
search that searches page content and attachment content (if the
attachment was indexable).

The xapian support is still under development, but got some fixes
recently that will be in 1.7.0 (some also in 1.6.4).

> BTW, I really expect this to be a fair amount of media data.  I know of
> at least a gig ready for a wiki now.  Can anyone offer up their
> experience with attaching this much data to MM pages?  Does performance
> suffer?

moin up to 1.6.3 had some issues for some server methods (wsgi and
fastcgi) - it loaded whole file into memory. This is fixed meanwhile and
will be in next release.

Also, you shouldn't attach ALL your attachments to a single page, this
would be also slow due to other reasons (when ALL means hundreds,
thousands, ...).

Having up to 100 or so attachments per page should be fine, though.

> Finally (and this really isn't a question, just an aside), I've read
> that MM 2.0 will/should/is-hoped-to-have a generic backend interface for
> databases or versioning systems.

Work happening on this within this "Summer of Code". :)

> I think this would be great, it would
> obviously solve my first question.  In some of my discussions with
> acquaintances that run their own WiKis, this seems to be a
> "look-down-on" feature-hole of MoinMoin.

Well, this will be really an important feature for moin.

But not due to reasons some "it needs a database" people always
think. :)


Cheers,

Thomas






More information about the Moin-user mailing list