SqueakPeople, SqueakSource, SqueakMap

goran.krampe at bluefish.se goran.krampe at bluefish.se
Mon Mar 8 11:05:23 UTC 2004


Hi!

Lukas Renggli <renggli at student.unibe.ch> wrote:
> Hi,
> 
> > Since I haven't yet implemented the replication mechanism making this
> > use possible (the idea of simply making local modifications to the map
> > and then "committing them" to the master) the new sites have created
> > their own models. And perhaps they would have done so anyway, 
> > especially
> > SqP since it is a borrowed codebase.
> 
> we had a look at the SM model, but we found that we need something more 
> fine-grained. Judge for yourself if this could have been done by reusing 
> the code of SM. We currently have the following roles in SqueakSource:

First of all - I wasn't really talking about code reuse - I meant using
SM as the backend.
But I assume you meant that too.

> - A *Superuser* (global role) has all the rights in all the projects. 
> This is useful if you need to change somebody's password or need to 
> clean up things.
> 
> - An *Admin* (project based role) is able modify the project settings, 
> create releases, read and commit to the project-repository.
> 
> - A *Developer* (project based role) is able to read and commit to the 
> project-repository.
> 
> - A *Guest* (project based role) is able to read from the project-
> repository.
> 
> - Usually anyone else is able to read released versions only (like 
> SqueakMap), however a project-admin might give read or read-and-write 
> permission to everybody in his project if he wants.
> 
> Cheers,
> Lukas

In SM there are currently 4 different things related to this:

1. Each SMAccount has a flag marking it as an admin. That is the
Superuser/root flag. Could have been done using categories, see below,
but for some reason I didn't. I am an admin. Others can be too.

2. An SMAccount can own SMObjects. This makes it the "owner". Only one
account can be an owner of an SMObject (=SMPackage for example).

3. An SMAccount can be a co-maintainer of an SMObject. This means he/she
can also manipulate the SMObject in question in ways that are dependent
on what it is.

4. An SMAccount is actually an SMCategorizableObject. This means we can
categorize accounts in any way we like. For example, I will very soon
add the categories "Guide" and "Harvester".

Given the above - and if SM indeed today had the replication model I am
striving for (which it hasn't) - then we could have created
SMCategories.... hmmm. No! I take that back. :)

Currently the categories *can* be used for attributes of an SMAccount
(Like "Is this account a Harvester?") but it *can't* be used to model
things like "Can *this* account commit to *this* project?". Interesting.
We might want to extend the SM model a bit in those directions.

Anyway, just so you know - I never thought you could have used SM in the
way I am describing - it just isn't there yet. I just wanted to explain
what my vision is/was.

regards, Göran



More information about the Squeak-dev mailing list