Comment 122 for bug 240067

I had an interesting talk with MoinMoin's main developer Thomas Waldmann. In sum, I just think Moin 2 is worth a look, it's a big improvement compared to the 1.x series. But note that it's alpha and it *needs contributors*. As for scaling, it seems it does the trick. Please take a look:

* ThomasWaldmann: btw, storage got the final rewrite a few months ago, now much simpler, very flexible

* RenatoSilva: cool, do you think the code is cleaner and smaller?
* ThomasWaldmann: yes, a lot, old backend storage implementations were about 10x bigger

* RenatoSilva: I've heard some dudes from LP pondering about putting wikis available for projects, they were wondering what wiki engine to use, maybe moin2 if available can make them reconsider this...
* ThomasWaldmann: well, it is not ready yet for production

* RenatoSilva: just found a bazaar-based engine, maybe this one is what they're planning to use: https://launchpad.net/wikkid
* ThomasWaldmann: omg bzr, btw we killed the hg backend we had. we found it is just the wrong approach. But with the stuff we have now, we can sync on top of all those storage layers. this is more generic than doing it in the backend (we don't have the sync code yet, but we have revision ids, parent id, etc.)

* RenatoSilva: some people are suggesting moin, as well as wikkid, but the staff needs to test what wiki they need, iirc someone said moin would not scale well for the thousands of projects hosted there. Do you think moin could scale for thousands of wiki instances?
* ThomasWaldmann: it scales as well as anything else, how much ressources a wiki eats always depends on what you do with it and how. If you do stupid stuff, it will be slow. If you do a lot of expensive stuff, it will be slow also. Dvcs is wrong way to go. we also had that idea, but it just solves a different problem, not the problem a wiki has.

* RenatoSilva: I think the issue here is just a basic wiki instance for each project, the problem is that there would be thousands of wiki instances, so I imagine they wonder if moin server would handle them all well
* ThomasWaldmann: dvcs is great for managing a bunch of project (text) files in the filesystem. Few metadata (file name, mtime), data in file. And all files together define some state of your project. A wiki rather needs revision control for single items. But items do not necessarily need to be stored on the filesystem. Also, you do not just have data, but also lots of metadata (and that idea is no way new, hatta has done that also with hg). But you just can't sanely store wiki revision data into a file.

* RenatoSilva: but what solution do you think for "distributed wiki editing" (basically offline edits and their merges)
* ThomasWaldmann: it would need a enhanced filesystem, with unicode filenames of arbitrary length, with related metadata stored together with the file. Such stuff does not exist (sadly) and even if it would, it would be no way cross-platform. Distributed editing just requires to solve 2 problems: transferring the changes (this is rather easy) and merging (this can be hard and can not be automated for any case), and to know what one needs to do, one simply needs revids and parents

* RenatoSilva: one simply needs revids and parents?
* RenatoSilva: I like the distributed wiki idea because it would allow you to edit the wiki offline, or at least parts of it, and so other people, then merging the changes
* ThomasWaldmann: in moin2 any revision has a globally unique revision id (made with uuid4), if that is the first revision of an item and 2 people edit it, both new revs have that revid as parent, if you bring together those changes, your item has 2 heads and you should merge it. Best case: nonconflicting content text change, merge automatically, worse: conflicting text content changes, merge manually, worst: conflicting binary content change, merge even more manually (no support from merge tools).

* RenatoSilva: so the merge thing is already sort of implemented? the only missing part would be "branching" and "pushing" offline stuff?
* ThomasWaldmann: the merge thing is not implemented yet but we have revids and parent, so the foundations are there. Our release goal for 2.0 is a basic, powerful wiki. Syncing and merging is a bit out-of-scope. So for me, that is rather for 2.1 or later. A dvcs mananges changesets globally (over all files). A wiki rather needs to deal with item revisions separately (== for single "files"). Also, as i said, it is not about files. but arbitrary metadata and data. We found that trying to use hg for that is kind of abuse.

* RenatoSilva: oh I see, but it wouldn't be that hard to implement these dvcs-like ideas, right? I ask because I think they're deserving it and it's a good idea anyway
* ThomasWaldmann: it is a lot of work, esp. the ui and the merge part.

* RenatoSilva: hmm but less than creating a new dvcs-backgrounded wiki engine I suppose
* ThomasWaldmann: yes, reinventing wheel is always worse

* RenatoSilva: can I paste this conversation there in the bug? I mean, maybe they get interested in moin2, realize wikkid is maybe a bad idea, and as it has attention of lots of people, moin2 could even get contributors for the sync and merge stuff
* ThomasWaldmann: well, feel free. just make clear that this stuff is still alpha and not yet ready for production. But some parts like the converters, the search, the storage is quite good already. I don't know wikkid at all, but what we found out for mercurial and moin might be true for wikkid and bzr also.

* RenatoSilva: oh no I don't mean they starting to use it right now, more than they get interested and even *contribute* :)
* ThomasWaldmann: yup, that would be great

* RenatoSilva: wikkid seems a wiki engine with bazaar backend, so not that useful according to your explanation
* ThomasWaldmann: well, such stuff CAN work for a simple wiki.