[pmwiki-users] ZAPForms: docs + future

Ben Wilson dausha at gmail.com
Wed Aug 15 09:02:03 CDT 2007


On 8/13/07, The Editor <editor at fast.st> wrote:
[...]
> I should note however that it may be more difficult than you think to
> progress--as the real problems, at this point, are limitations within
> PmWiki. You may be able to overcome them--but ZAP has already pushed
> PmWiki beyond it's intended boundaries, and Pm is not willing to
> extend those boundaries. To do so would require fundamental changes,
> that PmWiki simply cannot afford to make.

Again, I feel compelled to respond. PmWiki has a set of philosophies
and goals that have remained pretty consistent for the three years
I've used it. What Patrick has done by not acting on one recipe
author's request to change the Core is effectively refuse to support
one vendor. It's like the W3C changing HTML to something resembling MS
Word Document format solely to appease Microsoft. Patrick is amenable
to well-reasoned modifications to the core that satisfy the PmWiki
Philosophy.

I have yet to encounter an issue with the engine, especially since
most of it can be overridden. Don't like the wiki syntax? You can set
a variable that turns it off---then define your own. Don't like how it
HandleBrowse()es? Write your own. Its authentication system isn't what
I prefer, but I know I can change it as I need to. PmWiki effectively
has no boundaries because it is extremely flexible.

I have begun to refer to PmWiki as a framework, because it does all of
the heavy lifting for a developer. I recently mentioned that I was
working on a rewrite of XTodo (XRedux). I was able to establish core
functionality in 30 minutes because I could leverage PmWiki to handle
the rendering (and JSON to handle the file storage). Authentication?
It's in there because PmWiki provides. Session Management? It's in
there. Skin management? It's in there. ZAP support? Don't want it, so
it's not in there.

The limitations you've encountered in PmWiki are of your own design.
You are authoring your own wiki engine; a laudable effort in its own
right as there are too few PHP-based wiki engines available
(especially flat-file using). Heck, I'm working on my own Python wiki.
But, I would never show open disrespect for PmWiki in its Community;
that is unprofessional self-aggrandizement. I would especially never
"dis" PmWiki while suggesting everybody going to my wiki's web site.

Regarding features you seek:
   * Embedding code in a wiki page: This will be a security nightmare.
There are reasons why nobody does this. This has been discussed before
on this list, so I will let that lie.
   * User management: most of this is possible without creating a
whole new mechanism.
   * invisible data storage: Um, what? That sounds like you're
offering the same system as PmWiki offers (complete control).
   * Pagelists: Where's the value-added? Pagelists are already the
cutting edge of wikidom. Name another wiki that has flexible pagelists
like PmWiki? Don't like the output? I'll bet PmWiki will let you
cancel out what bugs you---just like everything else (e.g. VSpace).
   * Editable Skins: Hmm. you're really asking to be hijacked. This
gives access to the entire page, including the <head> portion.

> Most of these are either not possible without core changes, or require
> major plugins that reproduce significant sections of PmWiki code and
> bypass it's(sic) limitations. But then you are talking a gigantic
> application. And you best hope it all fits together right.

Again, you are antagonizing the Community with that. All the markup
changes you propose are possible sans core changes because the PmWiki
markup is fundamentally an add-on (which is apparent from its location
in the "scripts/" directory). Your email is a piece of FUD.

> This is one reason I raised the question of whether it's really best
> to continue development of ZAP.

Having viewed zapwiki source code that was deemed available for public
consumption, I offer another reason to question ZAP development. Not
least of which is...

> I should add, security, is not really the issue. Yes, Pm is a careful
> and knowledgeable programmer, but if you are using ZAP, you've already
> switched to ZAPwiki's security model whether you know it or not.

I offer that ZAP functionality (esp. embedded code in the wiki page)
is flawed by its philosophy. Once upon a time, nobody protected their
ports because the Internet was a big, happy, academic family. The
first worm changed that. My gravest concern about ZAP is lack of
security. Being told that adopting ZAP causes me to unknowingly adopt
that security philosophy worries me.

> Anyway, not trying to stir the pot, so to speak, but to encourage some
> hard thinking. Yes, of course, you have my full support and my help
> anyway I can. But before you put too much effort into ZAP, it might be
> worth it to really think through your bigger strategy. And come up
> with a plan first. It might help.

This infers that ZAP developed earlier sans planning. I'm quite
certain whomever takes up the ZAP banner will engage in proper
software planning and documentation. That last paragraph seems a bit
too patronizing for those who are supporting ZAP. I would argue that
now is the time to consider a complete overhaul---leave no stone
unturned. This is the same approach I am using with XRedux; an
approach I employ in my own (and others) code when earlier design
decisions have created a morass of maintainability. That's actually
one of the things I like about PmWiki---it is well-maintained and
consistent.

-- 
Ben Wilson
"Words are the only thing which will last forever" Churchill



More information about the pmwiki-users mailing list