<div dir="ltr">Ian and Tamara<div><br></div><div>I am not advocating PmWiki becoming bloatware or 'all things to all people'. Far from it.</div><div><br></div><div>And I think that the recipe system is great. I've created two recipes, it was a challenge for me, but I could do it, great.</div>

<div><br></div><div>My concern is the opposite. </div><div>If the PmWiki core is (too?) small, and (too?) many features are in the cookbook then</div><div>PmWiki websites will end up being inconsistent, with each PmWiki implementing a different subset of cookbook based features, fixes, and markup, depending on the knowledge and ability of the wiki webmaster to 'know' which extensions to use, and be able to install and configure it,</div>

<div><br></div><div>regards</div><div><br></div><div>Simon</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 4 November 2013 10:54, Tamara Temple <span dir="ltr"><<a href="mailto:tamouse.lists@gmail.com" target="_blank">tamouse.lists@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Nov 2, 2013, at 4:59 PM, Simon <<a href="mailto:nzskiwi@gmail.com">nzskiwi@gmail.com</a>> wrote:<br>
<br>
> I'm soliciting some discussion from the PmWiki community on the approach to having features and functionality added to the PmWiki core.<br>
><br>
> There are a number of PITS entries that request modest enhancements to PmWiki, most of which would benefit writers and administrators, that are not being added to the core<br>
><br>
> Is this because there is a desire to avoid creeping "featureitis",<br>
> or because there is not the capacity to do these changes, awaiting feedback, suspended, or some other reason.<br>
><br>
> Often a suggestion is made to add these as a recipe or configuration item in config.php.<br>
><br>
> My concern is that if PmWiki is 'all recipes' and 'no improvements' it leads to a 'balkanisation' by recipe of PmWiki (and some recipes themselves are balkanised - which to use?), that is to say that while my wiki(s) might use a number of these great recipes, other don't, and writers can't reply on the same markup or features across different PmWikis. Consistency and completeness (orthogonality) have a place.<br>


><br>
> Now personally I don't use C2 wiki, or Usemod engines, because they don't have 'enough' features. PmWiki fits for me in the sweet spot, good features, easy to install, extremely responsive developers, doesn't try to be to much or all things to all people.<br>


><br>
> But I'd like to see the core PmWiki improving too.<br>
><br>
> As an administrator of several wikis I'd like to see more 'out of the box',<br>
> We don't have any way of installing recipes automatically (think app store), so both an ongoing maintenance effort is required and quite some knowledge of Pmwiki is required to carry out such customisations and recipe installs.<br>


><br>
> over to you<br>
><br>
> Simon<br>
<br>
</div></div>I’d like to see the core improving, and it does. What I would definitely *not* want to see is the core expanding and PmWiki turning into bloatware. A smaller core with extensions is a much better way to build and maintain a system. Monolithism is rather awful to deal with on many systems. What I would love to see, though, is a package management system that makes installing and updating recipes and skins easier, and aids development of local and shared recipes and skins. This is rather ambitious, I know.<br>


<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>____<br><a href="http://kiwiwiki.co.nz">http://kiwiwiki.co.nz</a>
</div>