Re: Security (was: Re: Pier user in context)

> Yes, I know that this is a common way to think. What bothers me is
> this (from a naive point of view):
>
> - security should not something which is only be added (thats the
> nature of decoration), because what was added can also be removed or
> forget to add.

Well, as soon as the unix security package is loaded, the security  
decoration adds itself automatically to all newly created structures.  
There is no easy way, except by manually editing the object-graph  
from the inspector, to add or remove security decorations.

> It seems more natural to me that security is deep in
> the mechanism of objects (or better message send), like the vats in E
> or Islands in Croquet.

In my opinion this is something different. I want to keep as much as  
possible pluggable in Pier, so that users with different needs can  
use different security systems. There are already two security  
frameworks that both work nicely, that both have advantages and  
disadvantages, and that every user can decide to use or not to use.

> - if one say model or buisness logic, one could easily think at the
> multi tier architectures. Here it is a common way to say, security
> must handled be the database objects (for example), not by the
> objects which are only a viewer. My problem is 1) that these viewers
> are mediators of security and 2) that in complex systems  this
> viewers can be itself complex object with model-view architecture.

In Pier the security is not handled by the view, but by the model.