www.squeakworld.com!
Stefan Matthias Aust
sma at 3plus4.de
Mon Jun 5 11:01:36 UTC 2000
At 16:21 01.06.00 -0400, Mark Guzdial wrote:
>>Is there an access control list based user management in Swiki already?
>
>I don't know because I don't know what that is :-)
I know Zope (python based dynamically web site builder tool with a large
user community) which has something that I tried to described with the
above buzzwords.
Zope has users and groups of users with rights similar structured as
unix. Users or groups can read and/or write pages. Rights are assigned
for realms, typically folders and their subfolders - I think. You can also
have the right to assign rights. This allows a hierachical organization of
projects, with people who get responsibility assigned which again can
delegate these responsibilities.
As a Swiki hasn't a hierachically structured set of pages, this isn't
probably applicable. Still, one could have groups of users who are allowed
or forbidden to read or write certain pages - perhaps identified by keyword
or a regex.
>We have had various protection schemes in Swiki. (While only two years
>old, it's evolved alot at Georgia Tech -- couple thousand student and
>faculty users, over 120 Swikis, etc.) We've tried some where users had
>particular reading vs. writing vs. appending capabilities.
Yes, appending is very important. It's nice if you can add comments to a
page but you don't want that people can edit other people's comments. I
didn't know that the current swiki has this feature.
> In general, we've found them more interface trouble than solving real
> problems. Our current scheme is that:
>- Any page can be locked with a password, and
>- A whole Swiki can be placed behind user authentication
The current scheme might work in an environment where everyone wants to
cooperate. However, depending on the audience and context, sometime,
you'll have to face the problem that too much freedom can lead to destruction.
I know that the Dolphin people lost all their stuff a number of times at
least one time because somebody destructively edited pages. The other
times, they assume (I heard) that a search robot tried to follow "delete
this page" links ;-)
Regarding context. If you think of an intranet which has to store
important documents, transcripts of project meetings for example. Now
imagine that a project had to be canceled and everyone is looking for
somebody to blame for that. Now, surprisingly, the swiki-stored transcript
had changed, making somebody say something he never said. Before you can
argue that old versions are also stored and that he probably didn't change
it to his own disadvantage, he got fired by management. IMHO you have to
trust the information every time - and I want to read the name of the
editor and be sure that's only he who write this or have a clearly stated
notice that nobody is responsible for a certain part of information.
>This works pretty well, but more advanced schemes are certainly
>possible. Of course, none of our users have tried to produce a news site,
>so your demands may be greater.
Probably, but hopefully we can change (evolve) a swiki for these needs.
bye
--
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
More information about the Squeak-dev
mailing list
|