The big benefits would be Wiki:LiterateProgramming (i.e. easy documentation. See also Wiki:HyperPerl, although I don't intend to do it that way) and using all that SoftSecurity stuff for truly open GroupWare (eat that, EricRaymond). The biggest problem I can foresee is the LinkPattern. But I think I can hack that too by using patterns contingent on context.
The implementation of KeptPages needs a better diff tool, but I'm working with Cliff on that. I guess I'll fork the codebase and see what I can hack up when I get back from vacation.
By the way, one of the goals would be making minimal and easily repeatable changes to the UseModWiki base script. A true fork would be very bad. -- SunirShah
Features needed to get UseModWiki ready:
I guess the first step would be to download UseModWiki 0.90 and install it. Then, the goal will be to Wiki:DogFood it to the point where you can hack it from within itself. Or maybe CrystalPalace, which is a better first case. (And the eventual goal for the first project.)
One nice benefit of using a wiki is that I can encourage people to conform to my naming conventions through the LinkPattern ala GuidePosts. I'll bet you dollars to donuts UseModWiki doesn't conform to my standards. See Wiki:SelfDocumentingCode.
I wonder how to deal with the copypright nonsense of people contributing randomly.
There's also the concept of multiple check-outs. I don't know if that's really important. Then again, I'm mostly interested in this as a feasibility experiment. -- SunirShah
An approach I think would work well is to follow the Smalltalk image model. Suppose we took Perl as our language of choice. Each subroutine would have its own page and package, and each package would have its own page, including the main package. Globals and package variables would be declared on the package page. Subroutines would be localized to only their page. In keeping with the WikiAsUNIX? model, the PageDatabase backend would simply use Perl's convenient mechanism to distribute a package across several files; so one file per subroutine. With a Perl pretty printer, this could be very nice. If we made the script that implemented this a PublicScript via this mechanism, that would make it very much like a Smalltalk image.
That's the basic idea. Variations are still important: it would of course be valuable to display the Package globals on every subroutine page, or display two subroutines concurrently (e.g. when splitting a subroutine into two).
Also, in terms of the image model, there is no reason to limit the code to Perl. If we gave each page a MimeType?, we could write Python code next to the Perl code. Data could pass between the two simply by considering each a NetworkService?, and putting some MachineInterface glue in a global framework. -- SunirShah
One possible future idea is to make the combined system interoperate with a traditional source control tool like CVS.
Sunir, there is no license on script.pl, but is it allright if I incorporate it into the CommunityProgrammableWiki that I'm working on? That is mostly UseMod .92 so the licence is GPL. I guess most of script.pl is from UseMod so I'm asking about sub ScriptFromPage?. -- BayleShanks
Yes, that's fine. The license eventually will either be BSD or GPL, so you can just make it GPL if you want. -- SunirShah
thank you -- BayleShanks
multiple check-outs are needed, because ...
both problems are solved by checking out a private version of the code, thus isolating a single "programming-transaction" from other work. Having the code in a wiki structure would lessen the effects of the first. Using XP techniques would reduce the problems of the second.
See also :