Re: [Phpwiki-talk] PhpWiki enhancements and a humble request for some feedback...

[Rui C. <rui...@ac...>]

Joby Walker wrote:
 > Rui Carmo wrote:
 >
 >> On Saturday, Jan 25, 2003, at 00:30 Europe/Lisbon, Joby Walker wrote:
 >>>> 4) ACLs.
 >> Yep. I was just wondering if it was in the code somewhere. I started
 >> off from 1.3.2 stable, and pecking through CVS wasn't very
 >> enlightenting as to what the current state of affairs might be.
 >
 > Things have been delayed a bit.  Reni is the point person on this
 > project (with me as a second), but both of us have been very busy with
 > other stuff for the past few months.  I have just recently finished much
 > of my part (at least initially).  And hopefully we can get this part
 > done soon.
 >

That's great to know. We've been drafting a set of "ideal" Wiki 
characteristics at http://mac.against.org/space/LiveWiki, and that's one 
of the main topics of discussion (that and authentication, since we need 
to integrate with internal systems).

 >>>> 7) CVS - not as a backend, but as an integrated tool.
 >>
 >> Picture this: You have a RecentChanges-like page that tracks CVS
 >> commits. Commit comments can (easily) contain WikiLinks, hence
 >> providing direct links to Wiki nodes. Instant progress tracking ;)
 >>
 >> Check this out: http://cvs.cvstrac.org/timeline
 >>
 > Ahh... using the wiki to track a project in CVS!  Interesting.  I'd like
 > to hear more.

Well, the URL above points to a C-based tool that does exactly that. You 
  can try it out right there (it's self-hosted).

Wiki, trouble tickets and CVS are integrated into the same tool, and 
even though it is not quite TheWikiWay, you can set up an entire project 
site in no time flat.

But back to PhpWiki. The way I see it, PhpWiki could be extended to do 
most of the usual project management tasks:

- gathering requirements and change requests
- managing documentation
- assigning tasks
- managing generic tasks/tickets/bugs (with history)
- linking all the above to CVS operations (commits, forks, etc.)

This would require some decidedly un-Wiki things like more structured 
task/ticket form layouts and some hooks into CVS, but it seems doable.

(A facelift and a smart navigation bar tuned to project management would 
  help, but that's a given when you customize PhpWiki)

I'm using the Mantis bugtracker (http://mantisbt.sf.net, which is nice 
but with somewhat unstructured internals), and the real tricky thing to 
do on a Wiki would be good task reporting (and maybe a few Gantt charts 
- that Mantis needs too).

 >> Seems OK to me. But why Group Auth? PagePermissions would be the same
 >> issue, no? :)
 >
 > Correct they are part of the same project.
 >
 >> Is there any info on the database schema changes for those?
 >
 > Not necessarily.  Our first priority is getting doing things the
 > "WikiWay", so the primary user authentication system is based of
 > meta-data on a page with the name of the user.  Groups are similar:
 > members are in a list on a page with the same name as the group, and a
 > group is enabled by being list on a primary page.  PagePermissions will
 > also be meta-data.

Hmmm... I understand the need to pursue the WikiWay, but deploying a 
Wiki inside your typical company requires integrating it with an 
existing user/group model. I'll probably be patching our PhpWiki for 
Apache auth (letting Apache grab the credentials from an NT domain), and 
build a simple "drwxrwxrwx" - style access model.

 > I am also trying to abstract things so DB, LDAP, XMLRPC, etc versions of
 > elements can be written in the future without forcing a major code
 > revision.

That would be great. The current DB support is great, but more 
abstraction would be nice on several levels. I'm particulary interested 
in content "per se", as in supporting multiple content types within the 
Wiki and translating them to other formats as needed.

Anyone thinking along the lines of a content formatting pipeline? :)

R.