Just want to say thanks to all for taking up the ZAP project. And I will very gladly continue to help anyway I can. It will be great to see ZAP advance!
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. To illustrate what I'm talking about, someone committed to maintaining ZAP really should take a serious look at ZAPwiki--as it has developed so far in the last two months it is hardly recognizable in comparison with PmWiki's brand of ZAP. (www.zapwiki.org). Once you grasp conceptually what ZAPwiki does, you will be able to come up with a real roadmap for ZAP 2.0. If I were still using PmWiki, I would DEFINITELY try and built ZAP 2.0 off ZAPwiki rather than PmWiki/ZAP. Some of the things in particular I would see as absolutely critical are: * action pages -- building custom site & local actions right in the wiki, with an action bar including not just view & edit, but create, rename, copy, tags, delete/undelete, email, joingroup, title, backup/restore, data, import/export, whatever... * real member & group mgmt -- with easy (centralized), full access controls for everything. Self registration, login/logout, profiles, reset password, email verification, the whole works. * invisible data storage (even in source) and fine tuned data access authorizations so you have complete control over who can see every bit of data stored on your site. * fix pagelists to allow dynamically generated forms with real boolean search capabilities -- including fully indexed tags, links, data, etc. Cut out the div's and stuff that mess up the output. * rework forms markups to simplify code, generate full session control, solve order of processing problems, and automate locking mechanism for multiple forms on a page. And while you are at it (all indirectly related to ZAP): * true hierarchical pages -- applied systemically throughout the site, functions, and form commands. * in wiki skins -- secure, live editing of html/js/css and test results instantly. Fully flexible page zones system. * improved markup table with intuitive line spacing, etc. Get full control of your forms layout and output. 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 limitations. But then you are talking a gigantic application. And you best hope it all fits together right. This is one reason I raised the question of whether it's really best to continue development of ZAP. Pm is going as far as PmWiki is able in terms of forms processing -- within the bounds of PmWiki's philosophy. It may end up being wiser to stay within that philosophy (ie, limit yourself to those things you can creatively do with Pm's basic forms capabilities and scratch the rest), or switch to a different philosophical foundation that will naturally enable the kinds of things you want. But that's just my conclusion after many long, and enlightening conversations with Pm. 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. 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. Cheers, Dan _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
