[pmwiki-users] PData support for pagelisting images

Patrick R. Michaud pmichaud at pobox.com
Thu Sep 7 15:31:03 CDT 2006

On Thu, Sep 07, 2006 at 09:55:58PM +0200, Dominique Faure wrote:
> On 9/7/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> I fear you're about to disinter the threads about hierarchic naming
> conventions we had few months ago...


> ...anyway, we *need* an unequivocally way to address things like group
> or page names, page properties,... from wathever place we are refering
> from (other or including page, pagelist template,...).

Well, we have that, sort of -- the question is what to do with
relative links and properties when they appear in an included page.
Do they become relative to the including page (as happens now) or
to the included page (as many expect).

None of this affects anything for non-relative links or fully
qualified page variables.

> I can't speak for those already managing hundreds of wiki pages in big
> farms, since my current installations are not so plentiful, but I
> would really have such features available somewhere to experiment
> with.
> Why not adopt a version numbering scheme equivalent to what we already
> have in apache, linux,... aka reserve (odd for us) minor revision for
> stable/trustworthy version and even ones for experimental features
> such as these?

(I'm assuming here that you mean that numbers like 2.3.x and 2.5.x 
would be development, while 2.4.x and 2.6.x would be "stable".)

There are a few reasons I'm not fond of the even/odd numbering
system for PmWiki.  First, the odd/even distinction isn't always
obvious to people unfamiliar with Linux kernel releases, so that
newcomers would tend to gravitate towards the highest number,
without realizing that it's "experimental".  I much prefer the "-beta"
and "-devel" designations that PmWiki has used in the past.

Plus, it's worth remembering that the Linux kernel has a very
long timeframe between stable releases -- typically two years or
more between each of 2.0, 2.2, 2.4, and 2.6.  I expect PmWiki
to get new features on a tighter timeframe than that, and having
lots of major-point revisions may imply less stability in the
codebase than I think it ought to.

Also, another good way to experiment with features is via 
recipes, which does happen.  The current {$:var} syntax is currently
implemented as a recipe and not in the core; I haven't released it 
yet only because I don't want people to start using it and then
have things change suddenly in the core due to issues like the
one in this thread.  :-)

At any rate, I'm currently thinking that we'll probably do something
similar to the way we handled the "WikiWords enabled by default" to
the "WikiWords disabled by default" transition.  For include, we'll
have both options available, and changeable via an easy option setting
of some sort.  For a while we'll continue with the traditional default,
but remind people that a change is coming soon and they should 
test/switch to the new interpretation when they get an opportunity.
(This may be somewhat easier than in the past because the PmWiki.SiteAnalyzer
tools can issue reminders to those who haven't switched.)

Then, at some designated date we'll switch the default to the new
setting.  Sites that haven't been able to make the changes can simply
have the old setting set and everything will continue to work for them.
Eventually everyone will have switched (or positively elected the
traditional interpretation) and things go forward from there.


More information about the pmwiki-users mailing list