|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: Idea: Crossbreed a source code control system and a wiki
|
On Thu, Jun 26, 2003 at 08:42:58PM -0400, mjd-perl-pm@plover.com wrote:
>
> What if the source code for a software package such as Perl or Apache
> HTTPD were derived from a wiki? Each wiki page would be a function.
[MJD already said that each function would be a wiki page and that the
project would be named "wiliki".]
What about global variables, file scoped variables, function prototypes
(ala C/C++) and such? Would each have its own wiki page?
> Function calls would be hotlinked to their corresponding pages in the
> wiki. Documenation would be more wiki pages; comments in the source
> code might link to other wiki pages.
I wonder how this would compare to Knuth's WEB and Literate Programming.
Would this be Super-Literate Programming? ;-)
> Anyone who wanted to make a change would do it. After each change,
> the code would be automatically extracted from the wiki and rebuilt
> and the automated tests (other wiki pages) would be run. If a change
> resulted in new test failures, the test failures report would be
> automatically added to the wiki, as an annotation to the change that
> caused them.
Here we run into a serious security issue. Someone could add nasty code
that did something like `rm -rf \`. It would also not be hard to turn
the automated test into a spam machine. How would this be dealt with?
Is there a working Jail for Linux or some other way to sandbox the code?
Do conventional wikis have problems with cross site scripting or popup
windows?
> Periodically, a snapshot of working code would be taken and packaged
> and a new version would be released.
Would this be automatic, or would a human decide that a snapshot release
was appropriate?
> If you don't like that anyone can change the source code, replace
> 'anyone' with 'anyone on the development team'; wikis don't have to be
> public.
That would help with my security concern.
Just some other off the cuff thoughts here...
How difficult of a problem is it to parse source code written in an
arbitrary language out of a wiki's page source? I expect this wouldn't
be too difficult if the source was databased on the backend and the wiki
page generated dynamicly.
For things like C/C++ header files (and Java source files), it would
probably be useful to be able to specify which file a function or
variable, const, etc goes into. I'm sure this is obvious, but I didn't
really see any talk of this in the thread.
Could code dependencies be handled by wiliki, or would that be a testing
issue? I'm thinking of #includes, requires, uses, things of that
nature, not to mention linkage requirements for languages that go
through a link stage.
How long would it take to write a conceptual prototype? I don't really
know if wiliki is a good idea or not. It sounds neat. That doesn't
mean it would work well in practice though. Can some existing project
be back-ported into a wiliki format for test purposes, or would an
entirely new project have to be created from scratch? Hmmm. It would
be an interesting excercise to bootstrap wiliki this way.
Oh well. Just some random thoughts that may or may not survive GC.
--
David Steuber | telco:610.436.1677
302 E Marshall St | http://www.david-steuber.com/
Apt 612 |
West Chester, PA 19380 | Provoking new paradigms in thought and reason
-
**Majordomo list services provided by PANIX <URL:http://www.panix.com>**
**To Unsubscribe, send "unsubscribe phl" to majordomo@lists.pm.org**
|
|