[Moin-devel] Page Storage

[Thomas Waldmann]

Hi Kent,

> If the page storage structure will be changed, I would
> like to suggest the following:
> 
> Keep all pages under one directory, the supporting
> index and revisions in another.

If you are suggesting to go back to how 1.2 and previous versions did: 
it is rather unlikely we do that because we had good reasons to go away 
from that "structure".

What is a "supporting index"?

> The reason is:
> 
> 1. It easy the backup process. Exporting a wiki can be
> a simpler task.

That all depends on your needs. Some people might want to backup past 
revisions, too.

And if you use MoinMoin functions to enumerate pages and get their 
content, it doesn't really matter how the pages are stored. That way is 
far easier, especially if it comes to non-ASCII stuff.

> 2. Search engine friend, It will be easier to
> configure a local search engine to index and search a
> single directory instead of the current structure.

Sure. But this is non-standard usage. And a internet like search engine 
will use http, not file system access.

> 3. It will be easier to migrate one wiki to other. Or
> even merge two wikis into one. It is easier to restore
> and re-build after some failure.

I see no difference there. The new stuff might be even easier because if 
you want to copy over some page, you just copy it's bundle dir and don't 
need to collect stuff from multiple directories or split off / remerge 
stuff from editlog as in 1.2.

> 4. You will have a fallback plan to serve just static
> wikitexts when needed. Just config your webserver to
> serve the directory contain the pages.

That isn't really an option:
  * that completely overrides ACLs
  * it will serve unrendered pages
  * problems getting attachments, following links ...

> I dont known about efficiency of this scheme. But I
> think the operation of export, emerge, backup, search
> operation will be much simplifier.

Some stuff would be simpler, right. But other stuff would be more 
complicated or impossible. One example is RenamePage. In 1.2 and before, 
this was quite incomplete, it dropped all attachments, old revisions and 
page info.

Since 1.3 "page bundle" stuff, rename is easier and almost complete (all 
gets moved, only old RC entries not).

 > Also, a normal user will be quite easily find his way to the wiki 
text. An
> advance user will find his way to the support structure anyway.

The wiki is not intended for "normal users" to be used via the file 
system. And the "unnormal" people will have no problem finding the right 
file anyway. :)

> By providing a stable API to basic storage application
> will be a very good way.

Yes, stable APIs are nice. We try to have them after we found some 
storage structure that sucks less. :))

> I think forcing everyone to use xmlrpc is not good.

It is a stable API. :)

> 1. It load the system. 
> 2. xmlrpc is not always supported.

Python supports it via xmlrpclib. And the load should be a big problem 
usually, file systems access is always lots slower than processing some 
http request and parsing xml.

> For example, in case of a havily load system
> (slashdoted?), one might decide that making the site
> as static site temporarly. But when you want to do
> that, xmlrpc just not as stable as you wish.

If you really get slashdotted, nothing might help you.

You could of course try a static html export (see moin_dump), but a wiki 
where you can't edit or search isn't that great ...

> BTW, I would like to learn more about the wiki xmlrpc
> v2. Would you please give me some pointer or examples.

MoinMoin/scripts/xmlrpc/*

For the API either search the internet or look into MoinMoin/wikirpc.py.

If you don't like xmlrpc, you could also call some functions of wikiutil 
/ Page / PageEditor class. But you will have to change those for 1.4 (or 
2.0, how ever we call it when it is ready).

Thomas