[pmwiki-users] New Acme recipe...

[The Editor]

What's behind the post, Hans?  It makes me wonder why you are so
interested in knocking ZAP? If you don't like ZAP just focus
development on Fox? If you want to improve ZAP suggest improvements.
I don't really have time to deal with this kind of stuff, and you
probably don't either.  But for the communities sake here are a few
responses...

On 4/18/07, Hans <design5 at softflow.co.uk> wrote:
> Tuesday, April 17, 2007, 11:06:38 PM, The Editor wrote:
>
> >> - What's the official status
>
> > The code is quite functional and works well.  Most of it's commands
> > are in full operation at ZAPsite in the snippets section. Feel free to
> > take a look.  It's also quite well documented--now with numerous
> > tutorials as well as an extensive developers section. Hans changed the
> > status to beta for me because PmWiki is in beta status, and ZAP
> > requires the latest beta versions.  Other than that it is quite
> > stable.
>
> There is no official status for PmWiki add-ons released in the cookbook
> section. Pm does not take any responsibility for functionality or
> security regards to theses scripts. I think it is up to us, as
> a community of PmWiki users and recipe developers, to provide feedback
> about recipes and issue warnings where necessary, and correct errors
> on cookbook pages, if found.

If there are problems with ZAP I'd be more than happy to be notified
of them.  If none can be produced, insinuations ZAP doesn't function
are a bit groundless.

> I am as yet to be convinced about the stability of ZAP, as I have not
> seen working implementations of many of the claimed features on a
> variety of systems. To say that "Most of it's commands are in full
> operation at ZAPsite in the snippets section" is not itself a proof of
> stability. ZAP being an add-on module to process PmWiki form input, it
> needs to be used in a variety of forms for different purposes, and not
> only on www.fast.st/zapbeta, to be evaluated fully.

If you would like to test it for yourself, go ahead.  You might be
surprized. ZAP has undergone a lot of development over the last 4
months with helpful input from several users. It is easier to use now
than ever.

> If "most of the commands" of the code are working on a development site,
> one cannot truthfully call it anything more than "beta status".

I only said "most" because there are so many capabilities in the
toolbox, I have not had time to write a snippet for every single
command or every possible combination. They have however, all been
tested to work on my home Windows machine and my Linux server.

> Also: PmWiki is not in beta status. PmWiki 2.1.27 is available as a
> stable release. Only the newest development of PmWiki 2.2.0 is
> undergoing a prolonged beta series of releases, which are fairly
> stable in themselves, but have required configuration adjustments here
> and there by administrators.

No problem there. Actually when Pm introduces his Commenting system it
will likely heavily impact both Fox and ZAP as the page insertion
capabilities in both will likely need to be updated to take advantage
of it.  And no way to predict how that adjustment will change the
syntax of either at this point. But that's just one command among many
in ZAP.

> >> - Is it safe to use
>
> > No known security vulnerabilities or bugs.  All are fixed as rapidly
> > as possible. In some ways it is more secure than other processors as
> > it uses session variables for all it's major commands. Plus it has a
> > powerful config option which can enable you to completely lock down
> > the entire toolbox, and it's fully integrated into PmWiki's security
> > system via a custom forms submission password.
>
> I would love to hear other's opinions on this. Especially about the
> claim that using session variables makes it more secure.

There were serious issues raised early on in the development of ZAP
about the risk of forged headers being used to access a ZAP command,
so a system was designed (with Pm's generous help) to secure every
form submission. Furthermore, all but a few trivial core commands in
ZAP must be set using session variables (also upon Pm's encouragement
and recommendation) so a forged Post submission can not be used to
access any advanced feature in ZAP.

At the time I was not convinced the risk was likely but for the sake
of those using Fox, the security of his recipe should also be
considered carefully.  If post submissions are used to set the target
page and the content of the insertion, most likely a hacker could
exploit this with relative ease.

> >> - Do I need to use ZAP or ACME
>
> > The Acme Forms ZAPPING Engine is the name of the recipe. The
> > underlying code and scripts continue to be called ZAP.
>
> Meaning Dan has renamed the ZAP cookbook page "Acme". I don't know
> what zapping engine is though. Just big meaningless words to me.

Take it as a dash of humor if you wish.

> >> - What does the future look like
>
> > Only more stability. As PmWiki continues to add features to core, ZAP
> > will try its best to fully integrate those changes into its core, as
> > it has always done.
>
> Pm has said that he will most likely use {$$varname} syntax for
> replacement variables in future in PmWiki. When this comes into
> effect I predict ZAP will follow suit and change the {varname} syntax
> to {$$varname}. Then all of ZAP's forms need to be modified. Sites
> using the old syntax will break. I think it is only fair to mention
> this, as Dan has been warned by Pm that the {varname} may very likely
> cause conflicts in future with other pieces of PmWiki modules.

The templating feature has already been updated to use the new syntax.
I have not yet switched over to this for field replacements and don't
think I will. I like the simpler {field} syntax, and until a problem
with it can be demonstrated, I prefer to stick with it. It's also nice
to keep the syntaxes for field replacements and template insertions
different as they serve different purposes. It also allows me to put
template insertion syntax into fields without conflict within ZAP, an
advantage I believe outweighs potential disadvantages. I also suspect
should a conflict arise, there are workarounds that can be made
without having to scrap the field replacement syntax.  We'll see.

> >> - Why all these names
>
> > I chose the Acme recipe name in deference to those who think ZAP is
> > not too far off from Wiley Coyote's various contraptions. There's also
> > a note on the recipe page someone sent me from wikipedia that I
> > thought was especially appropriate. Feel free to continue referring to
> > it as ZAP if you prefer. Or the Acme ZAPPER or whatever.  It's all
> > still the same basic code.
>
> For the record:
> Dan was asked by a number of list members to change the name of the
> new MarkupExpressionsExtensions recipe to ZapExtensions, and he
> answered:
> > If you wish, but it tends to get buried down at the bottom of the
> > list. I'd rather keep it here, [...]
>
> In a follow on Dr Fred C wrote:
> > So long as the pmwiki search engine continues to provide a rather simplistic
> > alphabetical listing without attention to relevance, the most viable option for ZAP
> > like projects to get proper (or improper) notice might be to consider an "aaZAP" name
> > change, or perhaps use the Roadrunner/Wiley Coyote line of reasoning with "AcmeTools"
>
> So we can safely give Dr Fred C credit for the idea to rename the ZAP
> page "Acme", and deduct that Dan's prime motive for doing so is to get
> ZAP to the top of pagelists in PmWiki. Since the cookbook sidebar is
> now showing categories using pagelists I suspect Dan felt ZAP will not get
> noticed enough.

Three cheers to Dr. Fred!  And by all means, credit to him!  And no
question the pagelisting was a consideration. I prefer this method to
flooding the cookbook pages with ZAPthis and ZAPthat and ZAPsomething
else when they are all just various uses of the same recipe. That's
why I created ZAPsite, so I don't have to put all my documentation for
every possible use in the Cookbook, which I consider cluttered enough.
 (Pm's new reorganization is a big help!).

Just the same, it is true I wouldn't have gone with Fred's suggestion,
were it not for my various colleagues "who think ZAP is not too far
off from Wiley Coyote's various contraptions" yet fail to demonstrate
unfixed bugs or unplugged security holes. So they get a certain
amountof credit as well.

> But why this overly concern to be noticed? Why this salesman-like
> promotion of ZAP?
> Dan writes on http://www.fast.st/zapbeta/pmwiki.php
> > I am exploring the possibility, however, of developing an alternate
> > wiki engine that can run ZAP
>
> So apart from personal reasons I assume there is a business interest
> in promoting ZAP. In future you may be able to buy a ZAP Wiki which can
> "do absolutely everything", if you believe the sales talk, a la
> A.C.M.E.: "a company making everything". It seems to be Dan's goal,
> and he is using PmWiki and this community to achieve this.

I don't think Pm is the least concerned about me developing a wiki
engine that would compete with PmWiki. Nor do I think Hans you have
too much to be concerned about it either. ZAP was a genuine desire to
return something to the PmWiki community for it's kind help in
answering my questions and meeting my needs. It will remain so.

> >> In my book, ZAP appears unreliable for production use.
>
> I second that. I wait for ZAP to show being actually used in a number
> of form applications by others, to proof its stability by user
> testimonies.

No worries Hans, feel free to keep using Fox.  And if you find
something it can't do, you can always add it yourself. I do have
users, who find ZAP helpful. But I have nothing to prove to anyone. If
you can show a problem with ZAP, I'll fix it. If you are making
insuations, for whatever reason, there's no real way to refute them,
and I'd just as soon not try.

> I also wait to see the code itself be written more
> transparent for my limited PHP understanding, use much less cryptic
> variable names in the code, and comments in the code to explain
> functions etc. I think Open Software code is only as good as its
> code documentation. But I believe Dan will not do this with ZAP, as
> his own business interests for a future salable ZAP Wiki prevents him
> from making the code more accessible.

It has nothing to do with business interests. I prefer clean looking
code. I put the documentation on the support in an extensive
developers section that explain how each function works. If something
is not clear about a function--look there. Still can't find an answer,
I'll add it to the documentation. The fact is, I've provided more
documentation about ZAP than probably any other recipe on PmWiki.

> But maybe I will be proofed wrong on this, and ZAP will in future
> become reliable, trustworthy and transparent software. It would be
> great, and I wish Dan would improve it in that direction, instead of
> stopping development half way, because it has fulfilled his
> own needs.

I'll ignore another dig about it being unreliable and untrustworthy
unless you can point to something specific.  As far as transparent, it
is all GPL and thoroughly documented. And while it's true I'm trying
to freeze development in terms of new features for awhile--because it
now does about everything I want--I have every intention to continue
its support in terms of keeping up with changes in PmWiki and fixing
bugs or security vulnerabilities should they are found.

Finally, to the PmWiki community in general.  I've never claimed to be
a professional programmer, or that ZAP could not be written better.  I
would like nothing more than to have a few experienced programmers
(like Hans) look at the code and offer suggestions for improving it. I
have done the best I can, and it works for me. I only offer it in
hopes it may be of service to you in your needs.

Cheers,
Dan