<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Two points:<br>
<br>
1. Would it make sense to move this thread to the pmwiki-devel forum?<br>
<br>
2. I get a bit concerned when Patrick feels compelled to repeat points
previously made, particularly in relation to a challenge to his
legitimacy, or the legitimacy of his technical positions. It wastes his
time, and presumably saps his normally sunny demeanor<grin><br>
<br>
There comes a time when it becomes legitimate to say that a thread
doesn't belong here, and when challenges to Patrick become belabored
and inappropriate, even with Patrick's unique generosity.<br>
<br>
- Henrik<br>
<br>
Patrick R. Michaud wrote:
<blockquote cite="mid:20070601170430.GA6125@host.pmichaud.com"
type="cite">
<pre wrap="">On Fri, Jun 01, 2007 at 09:17:52AM -0400, The Editor wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">[...] Heck, it would
be more fun to write a program that would allow me to completely
overwrite your index.php at will with a user submitted post. [...]
</pre>
</blockquote>
<pre wrap="">What you fail to mention however is that this line is never run unless
there is also a POST field with the proper password value--a user
defined password, stored on the server and fully encrypted. So yes, if
some hacker could get that password, and they then forged a POST
submission, they could get control of your wiki. But then again why
bother forging a post if they have password?
</pre>
</blockquote>
<pre wrap=""><!---->
I think Ben's point is not that an attacker could get control of the
wiki, but rather that they could use this to get control of the
server. There's a vast difference between the two.
</pre>
<blockquote type="cite">
<pre wrap="">Or better yet, since this thread really is supposed to be about
PmWiki, why not answer ZAPwiki's conceptual challenges:
</pre>
</blockquote>
<pre wrap=""><!---->
Okay, I'll answer the "challenges". But I do have to point
out that I've already answered them _many times_ before.
</pre>
<blockquote type="cite">
<pre wrap="">1. A simple script for auto installing farm fields. How many questions
do we get about farm configuration issues?
</pre>
</blockquote>
<pre wrap=""><!---->
I've already answered this one, several times. If we have an
auto-install script of some sort, then how does it get executed?
If it's executed from a web browser, then any .php files it creates
will have to be owned and/or writable by the webserver account.
To me, that presents too many possible security vulnerabilities
for the server, and so 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.
One alternative is to not use .php files for field configuration --
i.e., make all configuration done by something other than PHP code.
While I've considered this in the past, and PmWiki uses non-PHP
files for configuring subsystems such as authuser, notify, intermap,
etc., I think it will always be the case that the flexibility
desired by site administrators and required by disparate PHP
environments will mean that there will always have to be _some_
manual configuration performed.
</pre>
<blockquote type="cite">
<pre wrap="">2) An optional, simpler page format? Ok, you addressed this one, but
your point was a dud.
</pre>
</blockquote>
<pre wrap=""><!---->
I've already answered this one as well. My points aren't duds.
First, the ability to use a simpler page format is _already_ an
option in PmWiki -- simply come up with a recipe that provides
PageStore objects that have the layout you want. If it ever
becomes popular enough, it can become a candidate for the core.
Second, I simply have a design preference that all text and
metadata (passwords, history, attributes) for a page be stored
in a single unit that can be easily moved from place to place.
I'm not a fan of designs where we have to be concerned with
keeping multiple files for the same object (page) in sync with each
other.
Lastly, it seems to me that the ability to edit files directly
on disk is of benefit primarily to the wiki administrator, or
people that have login/ftp privileges on the account. It doesn't
help the typical author (except for those environments where the
administrator _is_ the typical author, and likes to use text
editors on files).
So, this feature is one that appears to have relatively low demand.
(I'll grant that people who really want this feature may be choosing
other wikis that provide it, such as Dokuwiki. Still, it doesn't
appear to be a make-or-break feature for PmWiki adoption.)
</pre>
<blockquote type="cite">
<pre wrap="">3) Moving skin control to within the wiki.
</pre>
</blockquote>
<pre wrap=""><!---->
I don't have a need for this -- as a skin designer I prefer
to be able to specify the HTML and CSS directly in files and
not have to go through wiki markup to do it. This would also
seem to require enabling HTML and CSS in wiki markup , or
providing wiki markup sequences for everything that one might
want to do in HTML and CSS. I'm not a fan of either.
Beyond that, I don't think there's anything in the current design
that would prevent someone from developing a skin that does
_all_ of its layout within the wiki. But as I said, I personally
don't need it, and I don't hear a large demand for it. I _do_
hear frequent demands for being able to get very precise
skin control outside of what is typically possible in wiki
markup, or to integrate PmWiki with pre-existing templates
and sites that have their own skins.
</pre>
<blockquote type="cite">
<pre wrap="">4) How about a real form processing engine in PmWiki and a way to use
it instead of hardcoded site actions. Until you've toyed with this
some you have no idea how liberating (and efficient) ZAPwiki's
approach is.
</pre>
</blockquote>
<pre wrap=""><!---->
But, as we've amply demonstrated in the past, this also comes with
its fair share of security risks. And forms processing has never
been PmWiki's primary purpose, although that may change over time.
The PmForm module I'm working on is intended to provide forms
processing capability. However, I'm not looking to supplant what
we have now.
By advocating a "real form processing engine" instead of "hardcoded
site actions", what you're really saying is that we should
discard an awful lot of existing infrastructure (core code and
recipes) upon which PmWiki has been built. That may be a valid
approach, but in the overall scheme of things I don't yet see
the benefits of that approach as significantly outweighing the
drawbacks.
I also know that many times in the past you've claimed that ZAP
is intended for "non-programmers", but really much of what ZAP has
done is simply introduce its own programming "language" and
constructs, which people must learn to write in before they can
use it. Or, they rely on other people to write the ZAP code,
but that's essentially the "recipe" approach that PmWiki uses.
Yes, the ZAP language may be somewhat simpler than PHP, Perl, Java,
or other traditional languages, but just because it isn't one
of those languages doesn't mean it's not "programming", or that
it's substantially more accessible to non-programmers for the
level of capability provided.
</pre>
<blockquote type="cite">
<pre wrap="">To the rest of the list: if you try ZAPwiki--try it so you can see
what you're missing in PmWiki and then make a request PmWiki do
something similar. Use it to make PmWiki better.
</pre>
</blockquote>
<pre wrap=""><!---->
I'm all in favor of people trying other products and saying
"I really like this feature and wish we could add it to PmWiki".
For the most part I've tried to develop PmWiki so that even
if someone wants a feature that I'm not interested in pursuing
myself, it's possible to do it in PmWiki.
However, if the purpose of "ZAPwiki's conceptual challenges" is
to get me to shoulder the burden of developing and/or supporting
features that I don't need, don't seem to have much popular
demand, and that I philosophically disagree with from a long-term
design and security perspective, then I don't have much to add
beyond what I've said in the past. In many previous messages
I've already addressed these challenges, and cited the drawbacks
that I see from the approaches advocated here. ZAPwiki doesn't
really address the drawbacks I've raised -- it just ignores them
or treats them as being insignificant.
So, I think I've already answered the "ZAPwiki conceptual
challenges" in the past; ZAPwiki doesn't answer the counterpoints
I've raised to those challenges.
Lastly, you've made comments about ZAPwiki's smaller size, as
compared to PmWiki (I presume 2.2.0-beta). I think that's a
very apples-to-oranges comparison. PmWiki has trails,
supports multiple languages and character encodings, controls for
web spiders and robots, three types of caching, RSS feeds,
merging of simultaneous edits, automatically downloaded blocklists,
authentication from external sources, etc. So, for a more
representative comparison of code size, try comparing against
PmWiki 1.0.0 (2775 lines [1]), or even earlier. I think you'll find
that for comparable feature sets, PmWiki's code size has generally
been equal or smaller than what ZAPwiki is providing.
Hope this helps,
Pm
[1] Determined by counting lines in all .php files of pmwiki-1.0.0,
excluding scripts/layout-0.5.php which was used only for
sites migrating from PmWiki versions prior to 0.6.1.
_______________________________________________
pmwiki-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:pmwiki-users@pmichaud.com">pmwiki-users@pmichaud.com</a>
<a class="moz-txt-link-freetext" href="http://www.pmichaud.com/mailman/listinfo/pmwiki-users">http://www.pmichaud.com/mailman/listinfo/pmwiki-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Henrik Bechmann
<a class="moz-txt-link-abbreviated" href="http://www.bechmann.ca">www.bechmann.ca</a>
Webmaster, <a class="moz-txt-link-abbreviated" href="http://www.dufferinpark.ca">www.dufferinpark.ca</a></pre>
</body>
</html>