[pmwiki-users] on over-bundling

[Jonathan Scott Duff]

On Tue, Mar 08, 2005 at 09:51:49PM -0500, Radu wrote:
> Q: how can we keep pmwiki as effective for each application as possible?
[deletia]
> One of the PmWiki Philosophy points I like a lot is basically KISS (keep it 
> simple sir ;). However, many issues in the PITS are clamoring for more and 
> more functionality to be included with the default distribution.

Sure, but isn't that what the cookbook is for?  People prototype
features in the cookbook and then when enough "clamoring" happens, Pm
adds features to pmwiki.

> Now, I had suggested to Pm that a more modular distribution might be a
> good idea. Basically, a core wiki coupled with one or several mod
> paths. Sort of an extension of the current Download, Install and
> InnitialTasks, maybe leading in several directions.

Perhaps.  You know, there's nothing stopping you from building your
own pmwiki-as-blog or pmwiki-as-cms distributions.  I'm sure if you
did it, Pm would make a special place for them on pmwiki.org.

> Different people want to use the wiki for different things, so why not
> separate (possibly sort?) PITS issues based on use-niche (e.g. CMS,
> blog, project development...)

Sure.  You can use the category feature to bundle related PITS
entries.  Also, once everything is categorized, an "issue map" could
be made relatively easily (showing interdependencies among other
things).

> I already mentioned that the Cookbook is getting out of hand. If I'm
> not the only one who noticed that, let's brainstorm some ideas to deal
> with that problem. Maybe leave the Cookbook sorted by problem
> addressed, but add additional trails with features specific for each
> use-niche?

Certainly.  You can use categories here too.    In fact, one of the
interfaces to the cookbook could be just a series of links to lists of
modules that belong in a specific category (like search.cpan.org but
without the temple priests to do the categorization for us).

> That would allow the pmwiki core to do the core wiki things (provide
> infrastructure for various features, but not the feature details), and
> let recipes fill the gap to fully-integrated solution for each
> use-niche (which people could collaborate on maintaining at the end of
> each use-niche trail)

Er, isn't this what happens now?  You're just talking about making it
more visible or more formal it seems.

> Of course, maybe I'm wrong and we should all concentrate towards
> building a unique distribution that does everything for everybody...

No. Way.

PHP comes with batteries, tools, parts, pieces, instructions, stuff
you'll never need, etc. included and that's just a tad overboard (can
you say "understatement"? ;-)

Perl comes with a few useful tools and a way to get the other stuff from
CPAN but there's a barrier (configuring CPAN.pm and understanding how to
use it) to entry that makes getting the other stuff sometimes painful.

PmWiki should strike a balance between the two IMHO. And I think it
does currently. (It could maybe lean a little more towards the perl way
of automating things a little more, but that's probably just a bias on
my part ;-)

-Scott
-- 
Jonathan Scott Duff
duff at pobox.com