Re: the deadly hypercube of death, or: handling permissions

[Ludovic Courtès]

Hi,

On Wed, Apr 26, 2006 at 09:12:16PM +0200, Marcus Brinkmann wrote:
> The actual check if the transition is allowed or
> not must be done in the object implementation itself.  From a
> perspective of type purity, that is unfortunate (and must be
> considered a defect).  However, it is also the solution that provides
> the most flexibility.

I probably haven't thought about it as much as you did, but I tend to
agree with that (more on that below).

One consequence is that permission bits can be thought of as reserved,
implementation-specific bits and thus, they no longer need to be made
part of the "type" system, i.e., they don't need to be interpreted by
the type system --- and indeed, "permission" has nothing to do with
"type", and IMO mixing them is what's harmful to "type purity".

So you end up with the "real", regular object hierarchy where single
inheritance should suffice for most purposes.

> CapIDL could even generate automatic permission downgrade checking, if
> it knows the semantic rules of their interrelationship.  A simple rule
> would be to consider all permission bits to be independent.  However,
> as there is a good motivation to make the actual number of possible
> permission combinations as small as possible, and the server can
> easily implement these checks themselves, and implementing them
> explicitely allows for more flexibility in defining the semantics (for
> example, requiring that X is only present if R is present as well), I
> would argue for simplicity and flexibility and leave CapIDL ignorant
> of semantics of permission bits.

I'm not sure "permissions" and "downgrading" are concepts that could easily
be described within the interface description, and then interpreted
automatically.  One reason to this is that there can be various kinds of
relationships among permissions: "depend-on" relations, "conflict-with"
relations (maybe), and perhaps others.

Thanks,
Ludovic.