[Pmwiki-users] pmwiki-0.6.21 released with experimental WikiFarmsupport

[John Rankin]

On Sunday, 30 May 2004 2:47 AM, Steven Leite <steven_leite at kitimat.net> wrote:
...
>Any other differences between the current Wikifarms are just "features"
>as far as I'm concerned.  There are bound to be features that one
>Wikifarm has, and that the other doesn't.  The most helpful thing for a
>user in determining which Wikifarm to use will be to clearly list the
>"features", and briefly explain what they do and what the benefit.
>Other "features" my include overhead, ease of installation,
>configuration, etc etc ..
>
>-S
>
A farmer from Texas, on holiday in New Zealand, falls into 
conversation with a New Zealand farmer at Fieldays 
(http://www.fieldays.co.nz/home/page.aspx).

New Zealand farmer: Big spread back home?

Texas farmer: Well, let me tell you. I can go out of my front door 
at dawn, jump in my pickup truck, drive all day, and when the sun 
goes down, I still haven't reached the edge of my property.

New Zealand farmer (nodding): I have a car like that.


Summary: different horses for different courses
- the PmWiki farm is more like a wiki colony -- each field is 
  independent of the others (as a diversified agribusiness might 
  run many independent farming operations)

- the CookBook farm is more like a family farm -- each field is 
  connected to its neighboring fields and the home area

- it should be possible to install the CookBook wiki farm in a 
  field of a PmWiki farm and have it "just work" (but it probably 
  won't right now)

Suggested way forward:
Modify each version as needed so that it's easy to:
- use the PmWiki farm to establish a colony of independent wikis
- use the CookBook farm to turn an independent wiki (which may or 
  may not be part of a colony) into a family farm
- turn a wiki that's part of a colony into a family farm
- turn a wiki that's a family farm into part of a colony 



<longDiscussion>
Both implementations:
- allow one implementation of PmWiki to run multiple wikis 
  (called fields)
- support farm-wide and field-wide customisations (eg to enable 
  or disable uploads)
- require no new markup

But:
- fields in a colony are independent (clicking the logo takes 
  you to the field home page and there is no obvious connection 
  to other fields; there is no visual cue that this field is 
  part of a farm)
- fields on a family farm are connected (clicking the logo 
  takes you to the farm home page, there's a new link to the 
  field home page, and each field has links to adjacent fields)

- groups in a colony are independent (there is a shared 
  wikilib.d, but if you edit and save one of these pages, the 
  saved version becomes local to that field; each field has its 
  own Profiles group; local group customisations are unique to 
  a field)
- groups in a family farm can be shared (by default, PmWiki and 
  Profiles are shared across all fields, like "the commons"; 
  the same local customisation can be applied to all groups of 
  the same name in different fields, if desired)

- fields in a colony can be administered quite independently 
  of one another (an administrator of Field A may have no 
  access to Field B)
- fields on a family farm can be administered together (an 
  administrator for Field A has access to configuration 
  details of other fields)

- adding a field to a colony requires an administrator to 
  set it up
- adding a field to a family farm is done by making a link 
  to it on the FarmPage

It seems to me that the 2 implementations meet different and 
complementary needs, but they are both called wiki farms. 
The PmWiki farm is more like a wiki colony -- each wiki 
field maintains its independence, while all share common 
code resources. Visitors to one field may not be aware that 
other fields exist. The CookBook farm is more like a family 
farm -- each field grows its own crops, but they are all 
visibly part of the same farm. Visitors see the field as 
part of something bigger.

So (PmWikiPhilosophy 3) the one you choose will depend on 
what you want to achieve. You might even need both, but 
that could be a problem right now; I haven't tested it.

Would it be a good idea to have one consolidated approach 
that covers the whole spectrum of requirements? There are 
arguments both for and against. On balance, I think they 
are better left separate for now, but somehow made 
mutually compatible.


A wiki farm is only a model: 
    "All models are wrong; some are useful."

</longDiscussion>
-- 
JR
--
John Rankin