[Phpwiki-talk] Re: Zip meta-data

[Steve W. <sw...@wc...>]

On Fri, 14 Jul 2000, Jeff Dairiki wrote:
> 
> Yes, I see your point --- however php-serialized() meta-data is basically
> human-inaccessible anyway.   I don't see much point in making the meta-data
> more easily accessible unless it's in some human-friendly format.

Very true.. does this make me a hypocrite? ;-)
 
> An Internet-messageish format might work well, for example:
> 
> ---Snip---
> Author: 12.34.56.78
> Version: 23
> Flags: 0
> Lastmodified: 2000-07-14T21:39:08Z
> Created: 2000-07-02T12:01:22Z
> 
> !!!Sample Page
> 
> Here's the page contents, with a WikiLink.
> ---Snip---

This works for me. While XML would be keen, "don't let the best be the
enemy of the good." (best=XML, good=simple reliable solution)

Human-readable and human-editable are good things... if the metadata is in
the Zip file it's hard to see, hard to edit. With simple plain text files
you can write ex scripts to manipulate them, Perl scripts to transform
them, change them in Wordpad, etc. (Admittedly I've been reading "The
Pragmatic Programmer" again ;-)



> (If we're devising our own metadata format, I see no reason to separate the
> metadata and file content into two separate files.)
> 
> Is this a good idea?  Is it worth the effort?  (Actually it's probably
> not that much effort...)

One file probably is better... and the mail-message format is simple and
tried-and-true. NNTP also uses a similar format.
 
> Also, what's the thinking about whether we should include all the archived
> versions of a page (rather than just the most recent) in the ZIP?
> 
> I.e.: do we want to be able to:
>   1) Make a snapshot of the complete state of the database (all versions
>      of all pages)?
>   2) Make a snapshot of the current state of the Wiki (most recent version
>      of all pages)?
>   3) Have the option to do either 1 or 2?
> 
> If you chose 2 or 3, a secondary question is: what are the semantics of
> "restoring" from a type 2 snapshot?  Some choices:

>   A) Wipe the entire wiki, reinitialize from the snapshot.
>        o Archived pages are lost.
> 
>   B) Essentially edit each page in the wiki so that it coincides with
>      the page in the snapshot:
>        o Resulting page version number won't necessarily agree with snapshot.
>        o Lastmodified date should probably be set to time of restore, 
>          rather than the time in the snapshot.
>        o Current (pre-restore) version of the page gets archived?
> 

This parallels the question "How do you restore a project to a particular
release tag (in CVS)?"

I suppose in an ideal world, you get a nice wizard box that steps you
through all the choices for getting a snapshot, from the "whole thing" to
"just the pages, no metadata." But in a practical sense, the thing that
concerns me is having a simple way to make backup copies, and a way
to port from one Wiki to another.

Anyway, my suggestion is: do the simplest thing first, which in fact
you've already done since I can make Zip files of PhpWiki.. your choice of
what comes next! I favor #3 and #2 in that order. Restoring a Wiki should
work through the InsertPage() interface, so unzipping and loading a Wiki
would not overwrite existing pages but move them to an archive.

> In other news: the bug bit me, so I've started working on a modularized, 
> OOPified
> version of wiki_transform and GeneratePage() (a la Arno's suggestions).
> When I get it to where I'm happy with it I'll post it here for comments
> before CVSing it.

Excellent! You know, CVS has the ability to allow you to develop your own
private experimental "branch" and tinker away w/o losing the benefits and
freedom CVS provide. I haven't tried it myself yet but if you used this
approach, others could check out your work and test it.

cheers!
sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain