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 _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
