4 Mar
2003
4 Mar
'03
9:25 p.m.
From: Lukas Renggli <renggli(a)hotmail.com>
Newsgroups: gmane.comp.lang.smalltalk.squeak.general
Subject: Re: [Q] CMS/Swiki development
Date: Tue, 4 Mar 2003 19:46:37 +0000 (UTC)
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