Feel free to join in and write any of this functionality. Once SPW is patchable (there's a good chance that I'll finish that part today), you will be able to submit a patch inside SPW itself -- the patch will be applied after a PeerReview period if no other SPW community member vetos it for further study. (of course, until a community is formed, you could also send me a patch which I could apply manually if you don't want to wait for the PeerReview period in SPW).
I'm very interested in adapting SPW to create a literate environment for programming. Some ideas along these lines (thanks to MitchellNCharity? and SunirShah):
Have one (or a few) functions per page in SPW. One way to do this is to use the upcoming patch functionality to have SPW create a patch based on edits to that page, so that you wouldn't have to break the real source itself into those different pages.
If someone changes the interface to a function then SPW would detect which other functions should also be changed to match that (and the backtracking comes in because then you want to trace back THOSE functions to see which ones should be changed, etc)
See also Wiki:HyperPerl?, MeatBall:InfiniteMonkey?, variable idea (forms in wiki pages) demonstrated on Wiki:SunirShah.
The issue is how bushy the version tree is allowed to get, and how to deal with it. Traditionally one tries to have at most a couple of main development branches. When patches accumulate which dont get integrated back into a main branch, and someone cares about them, the entire effort forks. It seems that wiki engine source does a lot of forking. One approach some source code management tools take when one has to deal with a bushy version tree is to keep track of patches as "first class objects", rather than mere artifacts of some particular branch's growth. That allows one to say give me branch L with patchsets X and Y added, and patch Z backed out. Playing this game with reasonable effort requires some tool support, one example of a useful (but not always needed) tool is dependency tracking.
Dependency tracking can be useful for development ("this patch depends on having a target which has the database-access-is-factored-out-as-a- separate-function characteristic") and for customization ("this patch creates a Search link, which should only happen if this wiki installation has been configured with a search engine"). But it is certainly not KISS.
-- Mitchell N Charity
:I think there's room for that sort of feature in a specilized software developer's, literate programming wiki. See comment below.
:One of my goals for CommunityProgrammableWiki is to supply a mechanism for wiki code forks to rejoin or at least improve each other later on, so this sort of functionality would definitely be useful.
:-- BayleShanks
I'm not sure whether I saw it mentioned anywhere, but if one could get and apply explict patches, ideally get sets of patches, then the population of self-hosting usermods could more easily evolve, doing the bacterial game of exchange of code fragments. Which would address the issue that usermod usage currently seems to be base usermod code plus selections from a menu of standard patches plus local customization. That collective patching exercise would be a nice one to also pull into the self-hostingness, rather than say only the local customization aspect.
:Great idea, thank you -- and then CommunityProgrammableWiki would assist in the current problem of coding effort being split between so many different wiki clones.
:Btw, see
::CommunityWiki:TooManyWikiEngines
:for more thoughts about how to deal with the aforementioned problem.
:-- BayleShanks
So I guess my thought boils down to making "patches explicitly visible, and ideally, clumpable" seems simple, and nifty as it helps support the bushiness inevitable in a population of many sites. But supporting bushiness in a single site's local codebase is a separate, rather more complex endeavor.
Hmm. Though if one did have local bushiness... perhaps one might do wiki.cgi?PageFoo?&codebase=Qa9w3E and get... I don't know, appearance customization? There seems some connection between bushy local code and things traditionally handled by templates, and customization variables, and user-specific customization info. TWiki has specially formatted entries on users' homepages which set customization variables. A random musing.
-- Mitchell N Charity
:My current push along those lines is to try to modularize the wiki paradigm a little more. Separate wiki code into "page database server" code and "client/UI" code. I've been writing a library to allow people to program wiki clients which would interface to existing wiki sites using a uniform API:
::InterWikiSoftware:WikiGateway
:-- BayleShanks
Modular patches remind me of MeatBall:PageClusters?. Maybe that analogy will help in the design of the interface. -- MeatBall:ChrisPurcell?
::Interesting.. -- BayleShanks
One thought I had a day or two ago looking at SPW - if one had an underlying source code control system with nice meta info (for interface identification, eg of individual functions), sets (for combining things into larger interfaces), flexible integration of partial diffs, and backtracking dependency resolution, one might just take the source and smash it down into individual functions, and then go through and annotate them with the assumptions they make about their environment. Then one could gracefully advance the resulting "mob" of components, rather than having to do the usual forking and "maze of twisty little passages" constraint resolution by hand. Hmm, though now that I've written out the requirement list, I realize it's still at the cutting edge of the source code control folks. Oh well.
-- Mitchell N Charity
I don't think it's overreaching to attempt things on the cutting edge of source code control; I think a SelfProgrammingWiki community may be powerful enough to solve problems like this. I think there is a good chance that applying the wiki paradigm to coding will lead to a more powerful collaborative development process.
-- BayleShanks
Source code management engines seem nontrivial engineering exercises. So rather than attempting to reinvent wheels, as you develop a vision of what scm support your system will need, you might look for existing scm projects which provide it, and slap wikiness on top. Maybe.
:Yes, I agree; I would like to have the code use CVS and Arch as a backend. CVS because everyone knows it, and/or Arch because it has special ways of merging different branches.
:However, I don't think that scm is tangential to what a CommunityProgrammableWiki ends up doing.
:I think that specialized CommunityProgrammableWikis will evolve for the software development of wikis. The primary function of these wikis is to serve as a communication and integration platform (LiterateProgramming?, etc) for software development (including development of their own software, and development of other wiki software).
:I think these variants include advanced features for keeping track of the bushiness of the version tree, and for porting wiki features from one branch to another. So, developing additional scm functionality as needed is not unreasonable. Certainly, though, anything that can be done by a standard backend such as CVS should be done that way.
:-- BayleShanks
As with wiki's in general, there is vast range of doable things, and the key seems to be finding a managably _simple_ "sweet spot".
Making usermod self hosting is a fundamentally neat step all by itself.
-- Mitchell N Charity
:Yes, I agree; one thing that I think I've learned from wikis is that the "sweet spot" makes all the difference. After all, there were various forms of community-editable text before wiki, but things just seemed to take a whole new turn when Ward made it simple.
:For me, I think the platform is right now too simple/not powerful enough. I think the key is to develop enough features that wiki developers begin to use the platform. Then those developers will add new features for development as needed.
:I think that providing tools to allow the version tree to become somewhat bushy will in the end further simplicity, as it will enable people to more freely refactor code ("hey guys, I just refactored the code and put my simplified version in branch BranchSimpleUseMod?").
:-- BayleShanks
See also OutsideLinks for links to pages on other wikis discussing the self-programming wiki idea.