[Q] CMS/Swiki development

Lukas Renggli renggli at hotmail.com
Tue Mar 4 19:46:37 UTC 2003


Hi Chris,

> I plan to develop a kind of Swiki that is more what I want (nothing 
> against swiki, but it's not really the thing I want :-) I think the 
> best  is with commanche.

I am implementing (with the Software Composition Group at Bern) a new 
Smalltalk Wiki implementation right now. There should be a first public 
version within a few weeks.

If you want to have a look at some documentation browse to: 

	http://scgwiki.iam.unibe.ch:8080/SCG/520

Unfortunately there is no public running prototype yet. Alexander will 
set-up a server very soon. Most of the needed code is there and working. 
We have about 150 Test-Cases that are most running green!

> 1) What would you say is the best starting point (It should 
> be faster than swiki)?
> - start from scratch
> - change the existing swiki

We considered using either SWiki or WikiWorks as a base, but did not 
like very much those systems from the design point of view. So we 
started from scratch.

> - build with seaside

In my opinion Seaside is really the best framework for any kind of web-
application. Unfortunately it is not portable to dialects not supporting 
continuations (Avi, correct me if I am wrong). And one of our goals was 
to have a Wiki that is easily portable between dialects.

> 2) What do you say about regular expressions. Is the plugin build in 
> in  the default VM or does the admin has to compile a new VM? Then I 
> had to  use Streams.

We have a parser building a tree of the content of a page. There are 
nodes for any kind of entities like paragraphs, lists, per-formatted 
text, internal and external links, smalltalk-code, ...

> - pages sit in a tree (swiki has a graph structure)

Not only the pages are a composite of nodes, also the whole wiki 
structure is a tree built of a composite. We do not limit to the model 
of SWiki (Shelf, Book and Pages), we may nest at any deep. As internal 
links are simply references to another entity, they automatically update 
when we move something.

> - userlogin
> - permissions (from user to admin)
> - permissions are bound to a user/page combination and are
>    inherited down the tree.

A good security framework is really a problem in the current wiki 
implementations. We have a model that is going to give the possibility 
to have fine grained security checks: e.g. different permissions to view, 
edit, add, remove, change, upload pages that might be attached to 
different groups of users.

I hope that I could give you a brief overview of what I am doing right 
now. As soon as things get up and running we are looking for 
contributors writing cool extensions!

Cheers
Lukas

-- 
Lukas Renggli
http://renggli.freezope.org



More information about the Squeak-dev mailing list