phpwiki-talk

Re: [Phpwiki-talk] Re: Zip meta-data

[Jeff D. <da...@da...>]

In message <Pin...@bo...>,Steve Wai
nstead writes:
>> An Internet-messageish format might work well, for example:
>
>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... 

I 'gree.

>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?
>
>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.

Yes, it would also be nice to use the ZIP archive to move a PhpWiki from one
database format to another.  I'd want to do this without losing archived
versions, so this required a type 1 archive.

I can definitely see the value of a type 2 archive as well.

So I'll proceed towards option 3...

>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.

My take is that unzipping a type 2 archive should work as you say.

Unzipping a type 1 archive should wipe the existing database.  This is
probably too dangerous to be done over the web interface.  I envision 
being able to specify a ZIP archive to initialize from  (instead of
pgsrc/*) in wiki_config.  In fact, once the unzip mechanism is in place,
I think we should eliminate pgsrc/* in favor of a pgsrc.zip.


Next question:

What should the structure of a type 1 ZIP archive be?

  1. One file for each version of each page; either in:
    1a. Subdirectories: 'FrontPage/1', 'FrontPage/2', ...
    1b. Funny-named files: 'FontPage~1~', 'FrontPage~2~', ...

  2. One file for each page.  Each file contains all versions of the page.
     If we use the internet message format, this becomes an 'mbox format' file.


>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.

Yeah, I know that that's possible.  I'll look into it and see if I can figure
out how.

Jeff

Re: [Phpwiki-talk] Re: Zip meta-data

[Jeff D. <da...@da...>]

I've just checked in a new version of wiki_zip.php3 (& wiki_adminform.php).

This does away with the secret zip header field for meta-data.

The pages are stored as MIME e-mail messages, with the meta-data stored
as parameters in the Content-Type: header.

I also added the ability to make a zip including the archived versions of
the pages.  In this case you still get one file per page, formatted
as a multipart MIME message: one part for each version of the page.

Jeff

Re: [Phpwiki-talk] Re: Zip meta-data

[Jeff D. <da...@da...>]

>The pages are stored as MIME e-mail messages, with the meta-data stored
>as parameters in the Content-Type: header.
>
>I also added the ability to make a zip including the archived versions of
>the pages.  In this case you still get one file per page, formatted
>as a multipart MIME message: one part for each version of the page.

Okay, so now how to use these zip files?  Here's how:

The CVS version now has a new config constant WIKI_PGSRC (in wiki_config),
which controls the source for the initial page contents when index.php3 
is first invoked on an empty database (ie. no FrontPage).

If WIKI_PGSRC is set to the name of a zip file, that zip file is used for
the initial page contents.  If WIKI_PGSRC is set to './pgsrc' then the
old behavior results.


Note that the unzipping code only supports the 'store' (non-compressed)
and 'deflate' compression methods --- furthermore the 'deflate' method is
only support if PHP was compiled with zlib support.

Also I'm somewhat unconvinced that the unzip code will work on deflated
data from all zip programs.  According to zip spec, the file CRC and
compressed file size can be stored either ahead of the file data, or
after the file data.  My code only works if its stored ahead of the file data.
(I think this is fixable, but is a bit of a pain --- one must determine the
compressed data size from the compressed data stream itself.)  I don't see
much point in fixing it unless this is a problem for some major zipper
(eg. PKZIP.)  (The unzipper should work on all uncompressed zip files.)

So far I've only tested this code with zip files from wiki_zip and from
Info-Zip's zip 2.3.  If y'all could test it on anything else you've got,
that would be great.

Jeff

Re: [Phpwiki-talk] Re: Zip meta-data

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

On Sat, 15 Jul 2000, Jeff Dairiki wrote:

> Next question:
> 
> What should the structure of a type 1 ZIP archive be?
> 
>   2. One file for each page.  Each file contains all versions of the page.
>      If we use the internet message format, this becomes an 'mbox format' file.

I like this one... also, you could parse a file that contains 20 versions
of a page, and start using InsertPage() from version 1 through version 20,
as a cheap solution to replicating the database. However if we store
diffs... things will get hairy.

sw

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