[cgiapp] Wiki as "Best practices" of CGI::App

[Peter Masiar <suppressed>]

Hi list,

There was a proposal couple months ago on this list to create
a CGI::App based wiki as example of "best practices".

And it was me who voted against it, suggesting instead to join development
of very good and mature wiki clone Twiki (at Twiki.org).

Well, times are changing.

First, I did not noticed names from list on Twiki. 

Also, at the time, there was big push in Twiki community 
for improvements in many areas, including user interface, 
ease of installation, and converting to OO code, 
which were not included, postponed, dragged on, not solved.

Some Twiki developers now even suggested to fork 
(and some did, with multiple incompatible mini-forks)
or to join development of another wiki engine.

Another aspect is that CGI::Wiki CPAN module was started.
But it is meant as training exercises in CGI::App. 
So not precisely best practices, or most usable wiki.

So I was thinking if list members are still interested, 
we can use experience of some Twiki developers about what to do, 
what not to, and create really good wiki. 
Using best ideas of other wikis, most intuitive design.

Features what are important to me and which are lacking in most
other wikis (but present at GPL Twiki - so we can reuse them) are:

1) user authorization possible (important for corporate use)
2) full version control
3) skins and themes for nice "look and feel", using CSS
4) attachments (pictures etc)
5) really intuitive markup language, possibly parameterizable 
   (but fixed markup if too hard or too slow)
6) easy to set up and upgrade
7) name space separated into multiple "sections", possibly hierarchical 
   (or at least flat 1 level of directories as Twiki does)

Re 2): version control implies using RCS/CVS and text files, not database - 
and is easier to install. Or have both database and text versions.

For version 2 later, also:
8) plugins to expand functionality without changing core
9) caching pages for scalability under heavy load
10) tons of cool features from all other wikis ;-)
11) being able to send and receive email - there are always somebody who 
   "does not get it" or is offline. Or as Twiki does, just send 
   daily email reminders what changed, and let user to check the page.
12) make it example of best practices

Of course I am open to discussion what to include and what not.
It's a wiki after all ;-)
And I want to put strong emphasis that Twiki has big installed base
in real production and corporate environmeant, lot of cool features,
and huge knowledge base about developmeant *and deploymeant* issues.
So it might be smart more to use this experience.

As Brooks says in "Mythical man-month" (not exact quote): 
"Plan to throw away first version, you will anyway".

So: are developers here on list still interested?
Or did they already joined other wikis? 
And if joined other wiki, which one (or which ones)?

I am still pushing for the changes in Twiki, but I want to dive
into OO and CGI::App, and I love concept of wikis and can see
how to use it in many ways - so I want to learn one wiki inside-out.
Best way to understand wiki guts - design and implemeant one! ;-)

So what do you folks think about it?

-- 
Peter Masiar, suppressed, (203) 764-8131
Yale Center for Medical Informatics (YCMI), http://ycmi.med.yale.edu
I am not a lawyer. My ideas are NOT binding for University.
In doubt, Yale policy right: http://www.yale.edu/policy/itaup.html 




---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed