phpwiki-talk

Re: [Phpwiki-talk] Re: Link tokenization

[Arno H. <aho...@in...>]

I gave this some more thought. Here's what I've come up with.
Let me state again that the wikilink table can be used
with or without link tokenization. The benefits of this table are not
bound to tokenization.

Pros:
   * Eliminate name collisions when merging wikis -- long term benefit
   * Easy automatic link fixing when a page is renamed -- short term
     benefit for a seldom (or not so seldom) used feature
   * pages (and their referencing links) can be deleted easily -- short
     term benefit for a seldom (or not so seldom) used feature.

Note that the last two points "Seldom vs. often used feature" depends
on what kind of wiki you are running. In common wikis they would be
used seldom I reckon.

Page deletes *without* deleting references can be easily done without
tokenization too.

Con:
   * Complexity and if it becomes too complex bugs may cause "Bad Things".


Other things mentioned:

 > Undefined pages can be listed separately (ListOfUndefinedPages)

This can be done without tokenization as well.
Or is there more to this and I've overlooked something essential?

 > >  3. Inversion of the pre-transform [is hairy]
 > >     (Eg. was the link entered as "WikiLink", "[WikiLink]",
 > >      or "[  WikiLink ]"?)

This is a moot point. Say links are always displayed as [WikiLink]
to editors afterwards. What's the drawback?

 > >  2. Bugs in transform code are more likely to cause
 > >     permanent changes/losses of page content.

Only if the transform code becomes too complex.

 > >  3. Faster page rendering.

Wether or not this is true: it's a moot point.


To sum it up: some (small?) short term benefits plus a long term
benefit weighed against added complexity.

I vote for postponing this change until 1.4. 
Eventually it will be done, but 1.2 is too early for this.

Let's concentrate on the high priority issues first:
- making phpwiki more modular for easier extension and customization
- refactoring the db interface (going oop?)
- adding new navigation possibilities through use of our
  new db schema.

When this is done we can roll out 1.2.
And then we can start the really crazy things.

Jeff, I'd really like to see the class definitions of your
transform code.


/Arno

P.S: I have to switch vacation with a colleague. This means that
I'm on vacation from Thursday until end of July. Probably without
email access, but unable to code on phpwiki for sure :(

-- 
secret plan:
1. world domination
2. get all cookies
3. eat all cookies

[Phpwiki-talk] Re: Link tokenization

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

On Sun, 16 Jul 2000, Jeff Dairiki wrote:

> As of yet, I'm not at all convinced this is worth the effort.  It's a big
> kettle of fish.  I see three reasons to consider saving the pages in
> a partially transformed state:
> 
>  1. Eliminate name collisions when merging wikis.
> 
>     So, I think this is a moot point.

Yes, I was recounting that I thought about the problem when I was trying
to merge two Wikis, not that it was a motivating factor here. Our criteria
here should be, will this bring real benefits?

>  2. Easy automatic link fixing when a page is renamed.
> 
>     I don't think this makes it worth the effort.  It will be easy enough
>     to translate the links (e.g. with my forthcoming generalized 
> wiki_transform)
>     in the raw markup.

OK...

>  3. Faster page rendering.
> 
>     This might be an issue.  However, if it is, I think the best way to speed
>     page rendering is just to cache the transformed HTML in the database.

Oh, I hadn't thought of that... but I doubt the gain would be much.

> Drawbacks of partial pre-transforming:
> 
>  1. Complexity.  (Not that I'm not a fan of complexity ;-? )
>  2. Bugs in transform code are more likely to cause permanent changes/losses
>     of page content.
>  3. Inversion of the pre-transform is another kettle of fish, especially if one
>     wants to ensure the the output of the inversion matches the original 
> markup.
>     (Eg. was the link entered as "WikiLink", "[WikiLink]", or "[  WikiLink ]"?)

No doubt, there is risk. "Fortune favors the bold." :-)
Point 3 is particularly troublesome though.

I sketched out a simple pair of algorithms to help me think about this:

On submit of a page:
   replace all links with tokens
   update list of links
   save page to db
   save list to db

On select of page:
   fetch page
   fetch link list
   replace tokens with links
   send page to user

So what are the possible benefits? Here's a list of what I thought of:

Undefined pages can be listed separately (ListOfUndefinedPages), page
names can be changed, pages can be deleted (and links to deleted pages
would be replaced with a message, or link to a different page)

Three things, initially. 

sw

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

Link tokenization (was Re: [Phpwiki-talk] Re: Zip meta-data)

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

In message <147...@da...>,Arno Hollosi writes:
>
> > > Or do you think we should store the intermediate state instead?
> > 
> > Yes, this is an idea I had a long time ago.
> > I thought that [...] it would open up some interesting possibilities
>
>Sure :o)
>I'm in favour of this change. We have to think about some side effects
>like links to pages not yet existing.

As of yet, I'm not at all convinced this is worth the effort.  It's a big
kettle of fish.  I see three reasons to consider saving the pages in
a partially transformed state:

 1. Eliminate name collisions when merging wikis.

    Well, before we can merge wikis we need an interchange format.  (Currently,
    this is shaping up to be my zipfile.)  Then, page name tokenization only
    helps if the interchanged format contains tokenized names.  I'm pretty sure
    this is not the greatest idea.

    So, I think this is a moot point.

 2. Easy automatic link fixing when a page is renamed.

    I don't think this makes it worth the effort.  It will be easy enough
    to translate the links (e.g. with my forthcoming generalized 
wiki_transform)
    in the raw markup.

 3. Faster page rendering.

    This might be an issue.  However, if it is, I think the best way to speed
    page rendering is just to cache the transformed HTML in the database.

Drawbacks of partial pre-transforming:

 1. Complexity.  (Not that I'm not a fan of complexity ;-? )
 2. Bugs in transform code are more likely to cause permanent changes/losses
    of page content.
 3. Inversion of the pre-transform is another kettle of fish, especially if one
    wants to ensure the the output of the inversion matches the original 
markup.
    (Eg. was the link entered as "WikiLink", "[WikiLink]", or "[  WikiLink ]"?)

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

[Phpwiki-talk] new tarball of nbtsc.org phpwiki

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

I added comments to some of the code this morning as I was figuring out
what it does... it's up on the FTP site now, which I cannot reach at the
moment so pick the URL off http://phpwiki.sourceforge.net/ if you can
reach it.

sw

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

[Phpwiki-talk] refactoring wiki_dbmlib.php3

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

I've checked in a version of wiki_dbmlib.php3 that should allow us to
refactor the access to the data store.. I checked out a fresh copy from
CVS and tested it, and it looks good (I can edit, save, view info, diff,
and retrieve the copy from the archive. This includes new code to pad out
the serialized data (with spaces via sprintf()) to make DBM files more
space efficient in the long run.

I am going to drop the HTML form for rebuilding the DBM files since a)
there's a Perl script and b) it would have been a very hairy process with
lots of file operations through a web browser, which scared me, and c)
space loss shouldn't be too bad anymore.

sw

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

[Phpwiki-talk] more on the DBM memory leak problem

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

I have been working on the refactoring of the DBM support, and came back
to the problem of the memory leak. I wrote a test script and did some
experimenting, and here's what I found:

When you insert a key/value into a DBM and that pair already exists:
   if the value is less than or equal to the existing value, the 
      space is reused, 
   else new space is allocated and the old space is not reclaimed.

The dbmdelete() function does not help at all. If you loop over a DBM and
delete all key/values, and then replace them with the same pairs, there is
no change in the file size.

However if you delete all pairs, close the DBM and reopen it and reinsert
all key/value pairs, the DBM file size doubles.

If you delete all pairs and insert new ones with slightly larger value
sizes you more than double the file size.

This would suggest (if I feel ambitious) that for a DBM implementation all
pages should be padded out to a certain size, say 500 bytes, and when they
are fetched the padding is stripped. This probably wouldn't be too hard
with the perl regexp package and spaces or $FieldSeparator.

test script below,
sw

<?

    $page = implode("", file("pgsrc/AddingPages"));

    $h = dbmopen("/tmp/AAA", "c");
    $time = time();

    for ($x = 0; $x < 500; $x++) {
       if (dbmexists($h, "$x")) {
          $page = dbmfetch($h, "$x");
          $page .= "$x$time";
       } 

       dbmdelete($h, "$x");
       dbmreplace($h, "$x", $page);
    }

    echo system("ls -l /tmp/AAA");

    dbmclose($h);

?>


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

[Phpwiki-talk] 1.1.7 up

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

I've posted to freshmeat.net, and updated the links on
http://phpwiki.sourceforge.net/phpwiki/, and d/l and tested the tarball to
make sure it's good, and it is... 

sw

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

[Phpwiki-talk] 1.1.7 imminent

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

I'm uploading the tar ball... carefully tested, no CVS files this time,
wiki_config.php3 is vanilla, etc...

sw

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

Re: [Phpwiki-talk] thank god for rain

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

On Sat, 15 Jul 2000, Arno Hollosi wrote:

> Quite useful. Nice output format.
> Have a look yourself:
> 
> http://www.red-bean.com/~kfogel/cvs2cl.shtml

Thanks, I'll try it!

> 
> Btw, could you clarify what you mean by your last entry in the TODO:
> 
> > The History list in the browser no longer tells you where an edit page
> > is; this happened when we switched to templating.
> 
> What is an edit page?

I had thought that when you view a page, edit a page, save the changes,
and go to the page again, the web browser's Go dropdown (the web browser's
History list) would look like:

FrontPage
Thanks for FrontPage edits
Edit FrontPage
FrontPage

In Netscape anyway, but I was mistaken, I just tested this on a 1.03
PhpWiki and the behavior is the same (apologies for implying you broke
something :-)

But since we don't want the user to go back anymore to make further edits
(they get the message that someone else edited the page, but it was in
fact them) it's just as well.

sw

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

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

[Arno H. <aho...@in...>]

 > > Or do you think we should store the intermediate state instead?
 > 
 > Yes, this is an idea I had a long time ago.
 > I thought that [...] it would open up some interesting possibilities

Sure :o)
I'm in favour of this change. We have to think about some side effects
like links to pages not yet existing.

Jeff: I guess you have to take this into account when creating your
classes for pages and stuff. Basically it means we also need a routine 
to transform the intermediate state back to 'normal' wiki markup for
EditPages. I guess this will lead to some major refactoring.


 > Yes, got it, it will go out in the 1.1.7 release, which I am close to
 > doing. Are you going to make any more commits?

No. Go ahead :o)

/Arno

Re: [Phpwiki-talk] thank god for rain

[Arno H. <aho...@in...>]

 > Here's what I have for the HISTORY file, please let me know if I
 > overlooked something:
 > 
 > 1.1.7 07/15/00: 

Seems complete.

 > I culled this list from
 > http://phpwiki.sourceforge.net:80/phpwiki/index.php3?CVS%20log%20entries%20for%20release-1_1_6%20-%20release-1_1_7.
 > 
 > which is what you get from:
 > 
 >    cvs log -d">2000-06-25"

Ouch - quite a list to walk through.
I use cvs2cl.pl to create a ChangeLog file.
Quite useful. Nice output format.
Have a look yourself:

http://www.red-bean.com/~kfogel/cvs2cl.shtml

Btw, could you clarify what you mean by your last entry in the TODO:

> The History list in the browser no longer tells you where an edit page
> is; this happened when we switched to templating.

What is an edit page?

/Arno

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

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

On Sat, 15 Jul 2000, Arno Hollosi wrote:

> 
>  > > One wish I have is this: make the wiki_transform generic enough, so
>  > > that it can be used for savepage as well.
> 
>  > This would allow the renaming of pages as well, and all links for that
>  > page would be changed automatically, e.g. SteveWainsteadEatsWorms to
>  > SteveWainsteadIsANiceGuy.
> 
> I haven't thought of this one :o)
> Wiki pages would still get saved as they are now, only that we save
> links in the wikilinks table as well. So, renaming a page would need a 
> larger function than simply replacing the pagename in the wikilinks table.
> Or do you think we should store the intermediate state instead?

Yes, this is an idea I had a long time ago. I had a problem at work where
we wanted to merge two separate Wikis and there were all sorts of
namespace collisions I had to think about. I thought that if all pages
links were stored externally, and the pages were stored with tokens, that
it would open up some interesting possibilities, among them the renaming
of pages and therefore all the links to that page. I had some other ideas
about the possibility of this architecture which I hope I wrote down
somewhere... if not we'll rediscover them! :-)
 
> Btw, I committed a changed UpdateRecentChanges() which adds a diff
> link :o) And I fixed two more magic_quotes_gpc=1 bugs. This time in
> wiki_pageinfo and wiki_diff

Yes, got it, it will go out in the 1.1.7 release, which I am close to
doing. Are you going to make any more commits?

sw


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

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

[Arno H. <aho...@in...>]

 > > One wish I have is this: make the wiki_transform generic enough, so
 > > that it can be used for savepage as well.

 > This would allow the renaming of pages as well, and all links for that
 > page would be changed automatically, e.g. SteveWainsteadEatsWorms to
 > SteveWainsteadIsANiceGuy.

I haven't thought of this one :o)
Wiki pages would still get saved as they are now, only that we save
links in the wikilinks table as well. So, renaming a page would need a 
larger function than simply replacing the pagename in the wikilinks table.
Or do you think we should store the intermediate state instead?

Btw, I committed a changed UpdateRecentChanges() which adds a diff
link :o) And I fixed two more magic_quotes_gpc=1 bugs. This time in
wiki_pageinfo and wiki_diff

/Arno

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

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

On Sat, 15 Jul 2000, Arno Hollosi wrote:

> One wish I have is this: make the wiki_transform generic enough, so
> that it can be used for savepage as well. Let me explain: sooner or
> later we want to populate the wikilinks database table. In order to
> get the outgoing links they have to be extracted from the document at
> save time. Extracting those links is exactly what wiki_transform does
> right now (among other things).
> 
> So some sort of PreparePage() or AnalyzePage() which transforms the
> wiki markup into a semi-state with placeholders and separate arrays
> for wiki links and external links would be most useful. It could then
> be reused in wiki_savepage.

This would allow the renaming of pages as well, and all links for that
page would be changed automatically, e.g. SteveWainsteadEatsWorms to
SteveWainsteadIsANiceGuy.

sw

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

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 

Re: [Phpwiki-talk] Towards reimplementing CVS

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

On Sat, 15 Jul 2000, Jeff Dairiki wrote:

> On what to archive:
>    I think we all agree that we don't want to archive everything.  The
>    question is how to filter out the small edits.
> 
>    When the author changes we should force the old version to be archived.
>    This keeps competing authors from wiping each others work.

I agree... author change == "commit"
 
>    So the question remains what to do when an author is editing his own work:
> 
>    Personally, there have been many times I've checked something into CVS
>    (or some other version control system) when I've almost immediately
>    discovered some braino and wanted to erase the checkin.
> 
>    I envision a check-box on the edit form labelled something like
>    "This is a minor edit.  Do not archive previous version."  The default
>    state of this button could be made to depend on the time since the
>    last edit (if it's been awhile, the default would be to make a backup).
> 
>    To me it seems better to decide at edit time whether a change is "minor",
>    than to try to guess whether the next change will be "minor".
> 
>    I suppose this is not incompatible with another checkbox labelled "commit",
>    which would set a PRECIOUS bit in $pagehash['flags'].

Doable; I would be happy with a "commit" button, but people would probably
just commit every change they make... hmm... maybe store whole versions
when authors change, and diffs when an author edits their own work? Just a
thought.

> Cool idea which just popped into head:
> 
>    Once the version history stuff is in place, must add 'diffs' link to
>    RecentChanges entries.
> 

I am drooling... :-)

sw

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

[Phpwiki-talk] thank god for rain

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

I couldn't sit in my apartment all day working on the project and
listening to CDs if it weren't raining.

Here's what I have for the HISTORY file, please let me know if I
overlooked something:

1.1.7 07/15/00: 

* Page diffs, with color
* MostPopular page added which dynamically tracks most viewed pages
  (MySQL only so far)
* Admin functions: page dumps, page loads, Zip dumps, page locking
* MySQL, DBM, mSQL and Postgresql support all functional and appear stable
* Full HTML compliance in page output
* Fixed raw HTML exploit in [info] page
* Perl script included to reduce the size of a DBM file
* documentation updates
* page source updates
* gazillion feature enhancements and bug fixes, no doubt necessitating
  another gazillion feature enhancements and bug fixes ;-)

I culled this list from
http://phpwiki.sourceforge.net:80/phpwiki/index.php3?CVS%20log%20entries%20for%20release-1_1_6%20-%20release-1_1_7.

which is what you get from:

   cvs log -d">2000-06-25"

sw

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

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

[Arno H. <aho...@in...>]

Jeff,

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

could you post your class definition, before you start implementing?
Maybe the list can give you some valuable feedback.

One wish I have is this: make the wiki_transform generic enough, so
that it can be used for savepage as well. Let me explain: sooner or
later we want to populate the wikilinks database table. In order to
get the outgoing links they have to be extracted from the document at
save time. Extracting those links is exactly what wiki_transform does
right now (among other things).

So some sort of PreparePage() or AnalyzePage() which transforms the
wiki markup into a semi-state with placeholders and separate arrays
for wiki links and external links would be most useful. It could then
be reused in wiki_savepage.

/Arno

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] Towards reimplementing CVS

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

In message <Pin...@bo...>,Steve Wai
nstead writes:
>
>And that's when it struck me that if she posted the page to a newsgroup,
>that this was the same thing as doing a "commit" in CVS. And that's when I
>had my moment of "Aha! | Doh!"
>
>This is my vision for version control for PhpWiki: the ability to commit
>changes; the ability to retrieve any previous version. Not too difficult.

Here's my thoughts:

On how many archived pages to keep:
   Some wiki's may have storage space considerations, so I think there
   should be some way of configuring how many archived versions to keep.
 
   I definitely agree that all archived versions of a page should be
   accessible to everyone.

On what to archive:
   I think we all agree that we don't want to archive everything.  The
   question is how to filter out the small edits.

   When the author changes we should force the old version to be archived.
   This keeps competing authors from wiping each others work.

   So the question remains what to do when an author is editing his own work:

   Personally, there have been many times I've checked something into CVS
   (or some other version control system) when I've almost immediately
   discovered some braino and wanted to erase the checkin.

   I envision a check-box on the edit form labelled something like
   "This is a minor edit.  Do not archive previous version."  The default
   state of this button could be made to depend on the time since the
   last edit (if it's been awhile, the default would be to make a backup).

   To me it seems better to decide at edit time whether a change is "minor",
   than to try to guess whether the next change will be "minor".

   I suppose this is not incompatible with another checkbox labelled "commit",
   which would set a PRECIOUS bit in $pagehash['flags'].

Cool idea which just popped into head:

   Once the version history stuff is in place, must add 'diffs' link to
   RecentChanges entries.



>At this point I wanted to apologize to Jeff for what I think might have
>been a miscommunication. When we had this thread I posed a few questions
>to Jeff about doing diffs between versions: was storage an issue? Is doing
>a diff between version 2 and version 99 hard/expensive?
>
>Jeff, I think I might have scared you or intimidated you out of doing what
>you were working on... storing the diffs of pages. If I did I'm sorry. I
>was asking questions so we could discuss the possibilities, not to
>question your objectives. I'd like to revisit that discussion again.

No, no ... no apology needed, no offense taken, no problem!

I think your points are quite valid, and I think you have completely convinced 
me
that we should get version control working first; then maybe add the storing
of diffs.

Applying 100 patch sets to generate version N-100 may well get to be too
expensive.  It might be best (in the long run) to save small changes as
diffs, but save the whole page when large changes are made.


Not to worry, I'm still planning on working on the version control stuff,
but since this is going to involve changes to the database API, I've sort
of been waiting for a concensus to develop on how that's going to go.

Jeff





 

[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 

[Phpwiki-talk] Towards reimplementing CVS

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

A while back, I mentioned that I had an epiphany of sorts while I was on
jury duty... after I explain it, you won't think it's so remarkable but
for me it was a combination of the "Aha!" experience, and "Doh! Why didn't
I see that before?"

I was sitting in the waiting room of the Supreme Court Building here in
Manhattan, which is filled with lovely WPA paintings of the city. I was
reading "Practical Internet Groupware" by Jon Udell, which is about using
SMTP, HTTP and NNTP in combination, across the intranet, extranet and
internet spaces. He goes on in length about using private NNTP servers and
posting in HTML, since Netscape Communicator and IE can read/write HTML in
newsgroups and mail (a powerful combination).

I stopped and thought about a probem we had with the Wikis at the New York
Times. My project leader Noreen was really enthusiastic about using the
Wiki for project documentation and she was dilligent in editing, adding
and updating. But as more people used the Wiki it got harder to keep track
of pages, what was out of date, who wrote what, and so on. In particular
we needed a form of version control.

And I thought, if Noreen edits a page and she feels it's complete and up
to date, she could then post it to a private (intranet) news server and
this would be a cheap form of version control. Once it's on the news
server only she (or an admin) could "cancel" the post.

And that's when it struck me that if she posted the page to a newsgroup,
that this was the same thing as doing a "commit" in CVS. And that's when I
had my moment of "Aha! | Doh!"

A while back, we (this list) started discussing archive issues and version
control, and I put off this post for a long time. But what I wanted to say
is: with source code and CVS, you make a lot of little edits, test it, and
then commit your changes. With a Wiki, you make lots of little edits, test
it (in the browser) and ... well, you're done. But we could add a "commit" 
feature and that would put a new version in the archive.. 

This way, I could make an edit to FrontPage, commit it, edit it again a
few months later and commit that, and I have two versions now. (Not
possible under the current arrangement, unless I came from two different
URL's.)

How many versions do we want to make available to the user? Apparently,
all of them:

"Though malicious damage to ?CoWeb pages was infrequent, accidental damage
was more common. A frequent cause was users overwriting one another's
changes during heated contributions to a single page.

"From the very beginning, ?CoWeb stored all versions of a page. Early
users then made administrator requests to get pages restored. Later
versions of PWS ?CoWeb allowed users to access the last three versions of
a page on-line, but even that proved insufficient. The latest version of
?CoWeb allows access to all previous versions of the page."

(from the forthcoming book "The Wiki Way," Addison-Wesley Press:
http://leuf.net/cgi/wikiway?SwikiGoesEdu. CoWeb is the Squeak Wiki,
formerly Swiki, at Georgia Tech.)

This is my vision for version control for PhpWiki: the ability to commit
changes; the ability to retrieve any previous version. Not too difficult.

At this point I wanted to apologize to Jeff for what I think might have
been a miscommunication. When we had this thread I posed a few questions
to Jeff about doing diffs between versions: was storage an issue? Is doing
a diff between version 2 and version 99 hard/expensive?

Jeff, I think I might have scared you or intimidated you out of doing what
you were working on... storing the diffs of pages. If I did I'm sorry. I
was asking questions so we could discuss the possibilities, not to
question your objectives. I'd like to revisit that discussion again.

sw

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

Re: [Phpwiki-talk] 1.1.7 and re: Catching up

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

On Sat, 15 Jul 2000, Arno Hollosi wrote:

> 
>  > That said, if you want something in 1.1.7 that isn't there now speak up;
> Maybe Jeff should clear up the ZIP issue first.
> As soon as 1.1.7 is out we can start TheBigRefactoringOfPhpWiki.

I've tried it and it works... you get a dump of all existing pages, sans
metadata, plus the other dumping features work reasonbly well (for beta
release), but I'll wait until tomorrow to see if Jeff wants to add
something more. (Or soonder if you reply now, Jeff! :-)

> A more rigorous testing of phpwiki would benefit us all :o)
> Maybe I just write a small perl script using wget and netcat.

Yeah, testing is always an issue. I don't know of anything that does what
we need, haven't looked though.
 
> E.g. you have a list of "10 steps to do this&that"
> So you have a numbered list for those steps (level 1).
> Point 1 checks if everything is here "* tool x, * tool y, * tool z"
> The tools don't have any order - so I'd like to use simple bulleted lists.
> Voila - bulleted list inside numbered list.

What came to mind, reading your example, is that it's easy to switch back
and forth between UL and OL while editing (that is, if the user changes
their mind). 
For your example it would suffice to do:

# point one
** item one
** item two
[...]
**item ten
# point two
# point three
[...]
# point ten

But I'm splitting hairs here... it's just as simple to do mixed [#*]
anyway, and we're in agreement. Whether my example works is an issue of
testing :-)

> I'm not sure I'm for a 100% oop approach - I'll give this some more thought.

When I set out in December, I decided on a non-OOP approach at the time
because I didn't fully understand the Wiki problem yet. I read once that
you don't really understand a probem until you've solved it once, and I
would like to think I've solved it now... 

There have been times in the last few months where I found myself wanting
a DB object and a page object, because objects are easier to work with
than a data structure and function library (sometimes).

OTOH, good OO design is *hard*. I've had to work with some really *bad* OO
designs (in Perl, at the NYT) and it can be a total nightmare. This is the
single most compelling counterargument I have: PhpWiki is a scripted Web
application that is completely procedural in design, fairly small, and
easy to maintain. For a lot of users, webmasters, sysadmins, and
programmers that means it's easy to tinker with. Not a lot of people know
OOP and OOD.

I think I am definitely in favor of a DB class, somewhat in favor of a
page class, and I'm not sure about anything more after that. I'd like to
see some proposed classes and we can discuss it. (I wonder if we can model
the classes in the Wiki?)

sw

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

Re: [Phpwiki-talk] 1.1.7 and re: Catching up

[Arno H. <aho...@in...>]

 > That said, if you want something in 1.1.7 that isn't there now speak up;
 > otherwise I will release 1.1.7 over the weekend.

No special wishes this time :o)
Maybe Jeff should clear up the ZIP issue first.
As soon as 1.1.7 is out we can start TheBigRefactoringOfPhpWiki.

Because of 1.1.6 I had a look into testing suites for web-applications.
So far I haven't found anything proper. I found tools that check
for links and stuff. But what we'd need is a tool that requests
specific URL's, does POSTs as well, and then checks not only that
a page is returned, but verifies the returned HTML as well (simple
diff or by using regexp rules) Does anyone know of a beast like that?
A more rigorous testing of phpwiki would benefit us all :o)
Maybe I just write a small perl script using wget and netcat.


 > > [...lists...]
 > Yes, but I'm confused. Is there a reason to allow arbitrary mixing?

E.g. you have a list of "10 steps to do this&that"
So you have a numbered list for those steps (level 1).
Point 1 checks if everything is here "* tool x, * tool y, * tool z"
The tools don't have any order - so I'd like to use simple bulleted lists.
Voila - bulleted list inside numbered list.


 > > About /lib vs. /admin:
 > > I think /lib is cleaner and reduces the clutter in the main
 > Hmm. I guess I'm in the minority on this one!

As I said: it isn't urgent. We have more important things to do.
In the long run /lib seems more appropriate.


 > * moving to PATH_INFO. Ari has code we can use. This involves more than
 > you think because we get things like $copy, $edit, $info for free now from
 > PHP and using PATH_INFO means we'll have to roll them by hand;

Shouldn't be too hard.

 > * refactoring the database interface, which will start with the DBM
 > changes and then involve a lot of search/replace of variable names
 > (renaming all instances of $ArchiveDataBase to $ArchiveTable, or something
 > better, for example);

I think this should go into 1.1.8
I'm not sure I'm for a 100% oop approach - I'll give this some more thought.

/Arno