[pmwiki-users] Any hope for 2.2.0 stable release?

The Editor editor at fast.st
Mon Jan 19 15:46:42 CST 2009

On Wed, Jan 14, 2009 at 6:37 PM, Petko Yotov <5ko at 5ko.fr> wrote:
> * OOP is not a goal in itself, but a means to some goal, and it is only worth
> the effort in some cases. See "OOP Myths Debunked" at
> http://www.geocities.com/tablizer/oopbad.htm .

Just a note or two of agreement here. There are many ways to organize
code--and in my limited experience, the simplest is usually the best
approach. Switching things unnecessarily to OOP will not only leave
out PHP4 servers (yes, some still use it), but will make the code less
accessible to more ameteur programmers. I have developed several
plugins using already developed OOP scripts and found them 10x more
difficult to integrate. Granted, I'm one of those "ameteur"
programmers--but that's exactly the point. PmWiki was so beautiful
because when still a novice I could quickly access and grasp what was
happening.  And then hack to my heart's content.

Pm's (and PmWiki's) genius is not just in the code, but in his gift of
teaching and his/its ability to engage learners. Please don't lose
this characteristic of PmWiki. I personally have been tremendously
blessed by it.

>> My three main feature requests: resource file management, an
>> administrative interface, and a form-based content entry option.
> * A recipe could be written to add an administrative interface. It may already
> exist. I have used myself for months a small snippet and I'll soon release it
> on the cookbook. It allows some selected config variables to be overridden by
> editing special wiki pages. Not form-based but does the job.

In my other post I mentioned BoltWire's use of a simple site.config
page, where most settings can be modified in a special wiki page as
desired. The php handling this feature gives dominance to config
settings in a php script (which can do more dynamic configuration),
but for most cases, simple system wide settings work fine. It's also
fully extensible, so any plugin can call a function which looks for a
specified config variable, and returns a default if not found. Meaning
the same page can be used for any and all plugin settings/options. The
php code is trivial--but it opens up easy in-wiki configuration.

I don't know if something like this is possible currently in PmWiki,
but Petko's plugin sounds promising. At most, it would take a few
lines to generate a simple hook which could easily be set to off by
default, if desired. It would require a scouring of the code to
identify every variable you might want to potentially allow support of
in-wiki configuring, but that can be done incrementally as the need or
interest arises.

> * There are more than one recipes for form-based content entry. One is PmForm
> by Pm, other is Fox by HansB, a third, new one, is Blogger by DaveG.
> There is also another wiki project inspired by PmWiki and ZAP, which I believe
> has more form-based administration options. See http://www.boltwire.com/ .
> Personally, I believe adding more features like these should be in recipes and
> not in the core. For the core, we should follow the PmWiki Philosophy.

Thanks for mentioning BoltWire :)  However I might disagree slightly
with your conclusion. BoltWire was created because of limitations ZAP
kept bumping up against within PmWiki, and even more as an experiment
to test the limits of making form processing more central to a wiki's
internal architecture. And for me personally, the results of that
experiment were surprizingly positive--in terms of increased
flexibility, smaller code base, and performance. Regardless of the
pro's/con's (Pm made many reasonable arguments for not pursuing this
path in the core), I tend to think Henrik may have something here.

Granted, PmForms can do basic data storage and retrieval. And Fox has
even more extensive capabilities. But a little open discussion in this
area might lead to minor changes in the core that could dramatically
reduce development time for web projects. Talking with developers at
other wiki's on occasion, I sense more of them are moving in this
direction. PmWiki is definitely out towards the front, but others are
closing in. I would recommend more aggressive work in this area.

By way of side note, after getting so excited about this "new concept"
so central to the spark behind BoltWire, I was surprized to recently
read these wikipedia articles. Worth taking a look at. At the very
least someone should add PmWiki to the list...


>> I think that the combination of targets such as these could take PmWiki
>> back from being a laggard, to leapfrogging to the head of the line.
> PmWiki is not laggard. I have not seen any other wiki that allows even half of
> the features PmWiki could plug-in, without the need to modify core files and
> potential problems on upgrades. Some core features like PageLists and
> PageTextVariables are quite unique in the wiki-world. The built-in search
> engine is better than any other wiki, with the best ratio performance vs
> CPU+fsystem usage.

I about choked on Henrik's statement here. Pm is one of the most
kindhearted and generous individuals I have ever encountered, and the
support community here is dynamic and helpful. This very thread is
certainly proof of that. If development has slowed, my guess the cause
is not so much issues revolving around Pm, near as much as around the
fact the code works so flawlessly to the satisfaction of so many
individuals. Bug reports, security vulnerabilities, feature requests
unsupported by some plugin, etc., are so rare the mailing list has
gotten to be a bit boring reading lately!  :)  That's not
laggardliness, it's just plain old good software.

There may be areas for improvement. (I threw my friendly 2 cents
in--and could suggest more). But to use a loaded word like "laggard"
struck me as a bit out of line. It's easy to fire stuff of by email
without thinking. Let's hope that's all this comment was.

> The only thing I believe would be better, is to enable UTF-8 support in the
> default installation, but currently it is difficult for the script to know
> whether the wiki uses or not a custom character encoding, so an existing wiki
> that upgrades could occasionally break. We'll figure something out.

There are scripts that can check a file for proper UTF-8 encoding, and
other utility scripts that can be used to convert entire wiki's from
one encoding to another. In researching this topic, I found it a
rather complex and challenging problem--but implementing the
transition ended up going quite smoothly. I'm sure it's simply a
matter of someone setting their mind to it and doing it. And for that
matter there's no one stopping someone from offering some conversion
utility as a plugin. Just a thought.

Best wishes to Petko in his new role. And congrats to Pm on finding a
good partner. Regards to the whole community.


More information about the pmwiki-users mailing list