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