[pmwiki-users] Conceptual challenges from ZAPwiki...

Patrick R. Michaud pmichaud at pobox.com
Fri Jun 1 18:06:38 CDT 2007


On Fri, Jun 01, 2007 at 06:25:48PM -0400, The Editor wrote:
> Thanks for the lengthy reply Pm, much appreciated. I posted a few
> comments below, but tried to keep it short, for everyone's sake.

I'll keep my comments very short here.

> >> 1. A simple script for auto installing farm fields. How many questions
> >> do we get about farm configuration issues?
> >
> >I've already answered this one, several times.  
> >[...] I've rejected anything that opens the
> >possibility to webserver-writable PHP scripts, and I have made
> >this reason clear in the past.  ZAPwiki doesn't present any new
> >concepts here that I haven't already covered, nor does it
> >answer the objections I've raised.
> 
> [...] for the one config file PmWiki would need to
> write, couldn't the permissions could be reset once they are created.
> Or the ownership of it? Or is that not possible?

I've been trying to tell you:  it's not possible.

On most unix systems, only the superuser (root) can change the
ownership of files.  So, no, neither the webserver account nor
the typical (non-root) account holder has any ability to 
change file ownership once a file is created.  

If the webserver account owns a file or directory (e.g., because 
a PHP script created it), then even if the permissions are
reduced to something "safe", another malicious script running
under the webserver account can change the permissions to
something unsafe, because the malicious script is running
as the account that owns the file.

> >> 2) An optional, simpler page format? Ok, you addressed this one, but
> >> your point was a dud.
> [...]
> I should note my timestamping system, the alternative to diffs, is
> stored elsewhere, but it works great in terms of undeletes, etc. 

...yes, but also at the cost of storing a full copy of each page 
version.  In other words, every edit, even minor typographical 
fixes, ends up creating a separate copy of the entire page.  For 
many sites this isn't likely to scale at all well.

For example, pmwiki.org currently has 5,700 page files on it.  So,
imagine what happens when every edit or update produces a separate
copy of the page being edited.  By way of reference, in just one
day (2007-05-31) pmwiki.org had at least 200 edits performed.  That
would translate into at least 200 extra copies of entire pages being
created every day.  One could hit a quota in a hurry.  And there
are limits, both actual and practical, to the number of files that
can be held in a directory, so the history files themselves need
to be subdivided into subdirectories somehow to avoid those limits.

> [...] Not sure what the speed impact is but it's gotta save
> time to not have to load all that stuff up you don't need.

You're wrong, at least to the extent that you may be implying 
that PmWiki spends any extra time "load[ing] all that stuff up 
you don't need".

PmWiki doesn't load the page history when it doesn't need it --
that's the purpose of the READPAGE_CURRENT parameter to ReadPage().
READPAGE_CURRENT tells ReadPage() that it can stop reading the
file as soon as it reaches the page history data.  And the page 
files are organized such that the most recent stuff appears earliest
in the page, so it's even possible to request things like "only
retrieve the last 7 days of page history" without having to read
the entire page history.

Conversely, if each revision of a page is held as a separate file,
then loading up the page history for any page may take a while,
as the system has to scan a potentially very large directory (including
all edits that may have been stored) looking for files that matches.

Storing each revision as a separate file is a clever approach, yes.
But as far as I can tell, it just won't scale well beyond fairly
small sites.

> If we could just catch a vision for the potential of
> incorporating a really good "scripting language" into PmWiki over time
> (ie Pm's version, not necessarily ZAP), the results would be
> fantastic.

I really have no aspirations to create yet another scripting 
language -- I feel there are too many around already.  Sorry.
That's entirely your aspiration and not mine.

Pm



More information about the pmwiki-users mailing list