[pmwiki-users] New ZAP Profile Vars...

[The Editor]

On 5/31/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Thu, May 31, 2007 at 09:11:41AM -0400, The Editor wrote:
> > In fact, if Pm should only add to the core an option for ZAP's default
> > login approach tied to encrypted password field in a users profile
> > page.
>
> Out of curiosity, what happens to the encrypted password field
> if someone deletes the user profile page?  ;-)

That account would be deleted. Of course the pages could be edit
protected to avoid that.

> Also, what about user login identifiers that aren't valid page name
> syntax?

You would have to require it in whatever mechanism was used to create
the login account. Or else the login would fail. Actually ZAP is a bit
more sophisticated--it runs a page name formatting function on the
member name input so if it's even close to a page name it will match
and authenticate. The same function I use to convert the name they
give when they register into an acceptable page name. Ben S. gave me
the idea and it works like a charm.

Also I' not suggesting it be the only authentication method used, just
one that could be turned on and off--as a security feature--in a
config file as desired. Probably what, two lines of code in PmWiki?


On 5/31/07, Ben Wilson <dausha at gmail.com> wrote:
> On 5/31/07, The Editor <editor at fast.st> wrote:
> > In fact, if Pm should only add to the core an option for ZAP's default
> > login approach tied to encrypted password field in a users profile
> > page. It seems that's about all you would really need to replicate
> > ZAP's basic member management system. Just a thought for those who
> > don't really want all the fire power in ZAP.
>
> I have to disagree with this: PmWiki changing its core behavior to
> adopt ZAP. First, you've already stated that ZAPWiki is to be an
> improvement on PmWiki, but not a fork. What I'm reading is that you
> want Pm to do the coding for your fork, which is unethical IMHO.
> ZAPWiki is a fork.[1]

I'm not suggesting PmWiki change it's core behavior, only that it add
a useful extension--one that *already* works perfectly in ZAP (and for
that matter ZAPwiki). I don't need the code for it--I was just
thinking those who don't use ZAP could then take advantage of a really
wonderful member management system. I don't need it for myself
Ben--I've had it for months. And it is tops (the concept). Once you
grasp how it works ou will begin to understand the implications of it.

> Second, changing the core is supposed to follow a compelling reason.
> If the entire community lobbied for a change, or if the change was a
> logical progression of an implemented, core feature, then the core
> should shift. AuthUser is the core user authentication mechanism. You
> should be able to shoehorn your security hole^H^H^H protocol into
> AuthUser rather than try to have PmWiki provide a new security
> mechanism.

Again, it's not a core shift, just a very simple extension. It has
nothing to do with security, or any need I have. It's actually for the
benefit of those too prejudiced against ZAP to give it a try!  : )
Actually, I was just thinking, it is so easy to implement, it should
be available in the core without having to load the entire ZAP engine
to make it available to users. But if Pm doesn't think so, that's fine
with me.

> I'm afraid the "default login approach" is akin to the wiki clock.[2]

No clue what you are talking about here. Sorry. You are over my head, friend.

> What amazes me is you assert ZAPWiki is a 'floor-up' design, yet
> you're basing it off of PmWiki, which suggests your "floor-up" starts
> in the penthouse, not the foundation.[3]

I should be releasing the code later today. When I do, you will see
(if you care to look) that the whole underlying structure and more
importantly the philosophy is radically different. Unless you are
talking about concepts in PmWiki. But the code--it's virtually
entirely new (and ZAP code of course). The entire download--code,
documentation, wiki setup, and all) is just over 50 K. And it's fast!
Do you really think I could tweak PmWiki enough to trim it all down to
that? And yet increase many of its capabilities?

It's only possible via a complete redesign of how the wiki works, from
scratch. You see, the problem with PmWiki is its own success. It has
generated so many powerful concepts and ideas, much of it's initial
design really should be deprecated--but it can't be because it would
break thousands of existing sites. Completely. If you start from
scratch you can do things radically different--and reap a world of
benefit. I'll post a separate thread on this topic later--but ZAPwiki
really is indeed, entirely new.

Let me add, I'm not recommending people switch from PmWiki. ZAPwiki is
probably nowhere near ready for a production sites--though I'm using
it already as such for myself... And Pm's mastery of the wiki world is
the very best benefit of PmWiki, and a good reason to stick with it.
Not to mention a great community--the best, and another valuable asset
of PmWiki. On the other hand, if ZAPwiki challenges our thinking here
at PmWiki and it results in improvements, it will be well worth it.

Take ZAP for example. Perhaps it's not the best code--or at least
didn't start out so great. But it did demonstrate how powerful a forms
processor could be. So Hans took a stab at developing something
better, and Fox was born. Now Pm, looking at both, is finally
crystallizing his approach--no doubt better code still. Perhaps it
would have happened without ZAP but I suspect ZAP stimulated ideas.
Even those who never touch ZAP have thus benefited from it in this
sense.

Similarly, I don't anticipate droves flocking to ZAPwiki--nor do I
want them. (Pm's donor base surely is pennies compared to the hours he
puts into PmWiki. A shame really. And I don't have time or knowledge
to support the kind of questions Pm does.). But if it challenges
assumptions in PmWiki and PmWiki is strengthened, even a little, we're
all better off. If I could get Pm to take over maintenance of ZAPwiki,
I'd be happier still! But little chance of that. : )  I already
asked...

So, while I'm not sure at all what provoked your outburst Ben, in this
case you strike me as completely off the mark in assessing the
motives, or even the content of my suggestion. And perhaps it's these
kinds of misperceptions that make a core feature like this most
needed.

Cheers,
Dan