I would like to add something from my experience. In my years of experience, when a software package tries to become "all things to all people", as Petko put it, it begins to lose its appeal. It becomes too large to effectively maintain and ends up with so many problems that fixing one problem creates a dozen more. It becomes "too big to succeed". I'm very happy that Pm had the foresight to use a cookbook recipe system for adding features, this helps keep PmWiki from going down the "too big to succeed" road.
I'm all for adding features which need to be added, but I feel that we should be careful to put features where they really need to be, the core versus the cookbook. Regards, Rev. Ian MacGregor http://www.ianmacgregor.net > On Nov 3, 2013, at 5:05 AM, Petko Yotov <[email protected]> wrote: > > Simon writes: >> My concern is that if PmWiki is 'all recipes' and 'no improvements' it leads > > I'd prefer using the correct words. You use 'no improvements' when you mean > 'not adding additional features that have had about a single vote in 4 years'. > > I'd like to imagine that PmWiki has somewhat improved during the years - it > works with newer PHP versions, many bugs were fixed, including critical > security vulnerabilities, internationalization support and tracking changes > are better now. > > It is also easier to find active recipes, thanks to the *-Users and *-Talk > pages. Even the new recipe template is better. >> 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. > > If you cannot use a farmconfig.php file with all your local customization, > for all your wiki fields, you can create a file with the features you need > and include it from config.php. I use a file named francais.php which is > included in the French language wikis I maintain. > >> 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. > > Yes, and when in almost 10 years of PmWiki usage others and I never needed > some feature, I'd be happy if PmWiki doesn't add it and try to be all things > to all people. If PmWiki is lacking some function or hook to allow a recipe > to enable that feature, we will add the function or hook, so that the people > who need the feature can add it. > > There are wiki admins here who deactivate some core features they don't need. > >> But I'd like to see the core PmWiki improving too. > > It probably is. But we may have to disagree on what "improving" means. > >> As an administrator of several wikis I'd like to see more 'out of the box', >> 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. > > Installing recipes automatically, if not done properly, can introduce > security vulnerabilities. So, someone has to write the app store, decide how > it works and how one can enable and configure the 'apps' (per wiki, per group > or per page?), debug it, publish it, debug it, support it. > > Are there any obstacles in the current PmWiki core that stand in the way of, > or hold up the writing of an appstore by someone? I'll fix them ASAP. > > Petko > > > _______________________________________________ > pmwiki-users mailing list > [email protected] > http://www.pmichaud.com/mailman/listinfo/pmwiki-users _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
