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

[Henrik Bechmann]

Petko,

I've been running PmWiki on a PHP5 server as well. Although there were a 
couple of minor glitches, Patrick addressed them, and everything works 
well now.

But I believe the next step is to stop supporting PHP4, by which I mean, 
transition more to the OOP features of the language, eventually exclusively.

I don't buy the contrarian view of OOP that you offer. The benefits of 
encapsulation, modularity, polymorphism, and inheritanc 
<http://en.wikipedia.org/wiki/Object-oriented_programming>e are well 
established, and virtually universally accepted. These include:

- Closer match between design objects and implementation objects, making 
development more successful.
- improved modularity, and looser coupling among modules, making 
development, including team development easier (very relevant to this 
discussion of considering moving to a community development model)
- more concise and re-usable code. In the case of PmWiki the code may be 
concise, but it certainly isn't easily re-useable (see below).
- availability of a wide variety of useful design patterns that apply to 
the OOP paradigm.

Furthermore, the developers of PHP are apparently committed to focusing 
on developing the OOP side of the language, adding improvements there 
that will eventually surpass the efficacy of the legacy part of the 
language, viz the new class autoloader 
<http://www.devshed.com/c/a/PHP/Auto-Loading-Classes-in-PHP-5/> for 
example. It would be prudent to position PmWiki to take advantage of 
this effort.

Finally, PHP 5 (and 6) are being positioned to address some of the 
long-standing language problems, notably the arbitrary organization of 
language functions (generally considered to be a mess), and the lack of 
namespaces. These are being addressed in PHP 5 and 6, from what I can 
see with an emphasis on the OOP side of the language.

You ask if there is a problem that you cannot see that requires 
migration to OOP. Have you tried to follow the PmWiki code? With the 
greatest respect for Patrick, it falls into all the traps available to 
structured programming, notably over-use of globals, and unending 
reliance on hidden side effects. You can argue that some of this was 
done for conciseness and performance, but it has the drawback of being 
difficult to maintain. In the current context, it has the drawback of 
being virtually impossible to maintain by a group.

Another benefit of a re-write, not to be dismissed, is that it is an 
opportunity to disentangle some of the concepts that have developed 
incrementally over the years. In other words to clarify the design of 
the product, and reflect this clarity in the new code.

Regarding features of the product:

The list I offer comes from many years experience in offering PmWiki 
based websites to a number of community organizations in Toronto (about 
30 sites, of which a handful are pretty active).

For an example of file Management, see for example DocuWiki's 
mediamanager. <http://www.dokuwiki.org/mediamanager>

I think the benefits of an administrative interface are obvious: it 
lowers the skill level required to manage the supported features, making 
the product more accessible, and greatly broadening its reach. This 
would be true even if the supported features were selective, not univeral.

I have seen and investigated the form based entry systems that exist. 
These are terrific efforts, but are (IMO) still early, and awkward.  
Based in my experience of supporting many PmWiki installations, one 
thing that I have found consistently is that for sophisticated use of 
wiki markup, the complexity of embedded instructions is a persistent and 
important barrier to authors. Support for customizable, configurable 
form based entry would IMO radically expand the potential user base of 
PmWiki, and owing to the very work that you reference, this feature is 
relatively accessible, but requires further development effort. 
Furthermore, it would greatly alleviate the pressure for a WYSWIG  entry 
interface.

I would add decent "feed" capability, including useful RSS support.

I'm sure others have need of features that they see in other products.

PmWiki is most certainly a laggard by now. The current version has been 
in beta for far too long (for well justified personal reasons as we 
know), while the rest of the world is not standing still. See for 
example habari <http://habariproject.org/en/habari-and-php5>

In any case, surely as a product matures, if it is to become established 
in the long term, it requires an active community of developers to 
sustain it (for the core!).

My contention is: it is time for this to happen.

To be clear, I do not mean in any way to diminish the accomplishment of 
PmWiki. Instead I am arguing in favour of a clear way forward, to 
consolidate the gains made, and establish a foundation for capturing 
even higher ground.

Nor, of course, is any of this to suggest in any way the replacement or 
pre-empting of Patrick. That would be awful, as he's the genius behind 
this product. Instead, my initiative is aimed at finding a practical way 
of organizing support for him and his efforts. I would hope and expect 
that he would continue to be the designated "guru", the final say, but 
in more of an "executive" role.

Best regards,

- Henrik

Petko Yotov wrote:
> On Wednesday 14 January 2009 20:02:46 Henrik Bechmann wrote:
>   
>> FWIW, if there was to be the formation of development team, I think it
>> would be worth considering going (more or less directly) to version 3,
>> being a migration to PHP5 and OOP.
>>     
>
> * I have my PmWikis running on PHP5 since 2005. The current stable and beta 
> work extremely fine with PHP5.
>
> * 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 .
>
> PmWiki uses an OOP PageStore class that allows excellent integration of 
> different storage mechanisms such as a database instead of or in addition to 
> the filesystem, or a different filesystem configuration. Almost every other 
> aspect of PmWiki can be configured via enabling a variable and providing a 
> replacement function, without modifying core files. Every core script, should 
> it be changed, may be placed in the /cookbook/ directory and be included 
> instead of the original one. 
>
> Is there a problem I cannot see, that requires migration to OOP?
>
>   
>> My three main feature requests: resource file management, an
>> administrative interface, and a form-based content entry option.
>>     
>
> * What is resource file management?
>   - Deleting attachments is possible wia recipes : Cookbook:Attachtable
>     and others
>   - Uploading CSS files or whole skins via PmWiki's ?action=upload can be
>     made possible by adding two lines of code to farmconfig.php.
>
> * 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.
>
> * 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.
>
>   
>> 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.
>
> 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.
>
> Thanks,
> Petko
>
>
>   

-- 

Henrik Bechmann
bechmann.ca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20090114/bbe4e139/attachment.html