[cap-talk] Resource limitations (was: On revocation...)
Jed Donnelley
capability at webstart.com
Sat Dec 9 19:18:52 CST 2006
At 12:39 PM 12/9/2006, Marcus Brinkmann wrote:
>At Thu, 7 Dec 2006 11:49:57 -0600,
>"Karp, Alan H" <alan.karp at hp.com> wrote:
> >
> > > > The server can always refuse if a given capability has been
> > > delegated
> > > > too many times.
> > >
> > > As Neal said. Or: "What's too many?" [1]
> > >
> > That's a policy decision on the part of the server.
>
>But the server can not make a meaningful policy decision here. It's
>both the wrong party to allocate the resource and the wrong party to
>manage the resource allocations.
I feel you are nit picking here. I believe Alan's comment about the
"server" making such a policy decision is very much like, say,
Unix deciding about how many inodes that it will allocate or
perhaps in Windows the size of the virtual memory file. You can
argue that in all such cases as you say, the system is "the wrong
party to allocate the resource and the wrong party to manage the
resource allocations.", but that is the way current systems work
in these areas. Doing so is a practical choice because it
avoids complexity in other parts of the system and in practice the
limits can be set high enough that they are seldom a problem.
> > If the choice is
> > denying this delegation or crashing and denying all service, the choice
> > is obvious. In Client Utility each client had a quota that set a limit
> > on how much of the server's storage that client could use. Each
> > delegation consumed storage that was charged against that quota.
> > Reached your quota? Delegation denied. If that meant you couldn't get
> > your work done, tough.
>
>I would like to have an operating system in which people can get work
>done.
People can get work done in today's systems with exactly these sorts
of limits. This is not an area where I am personally trying to
make improvements. My goal is to establish a common and convenient
mechanism for doing access delegation with the properties that
people and programs need for their real work. Ideal for me would be
mechanisms that could be mapped from the language level to the OS
level and of course, my favorite, to the network level.
I admit to having a rather single minded focus in this area, but I
believe this sort of focus is appropriate for a list like cap-talk.
It seems to me that making changes for more explicit control of
internal table space for servers falls into another area.
--Jed http://www.webstart.com/jed-signature.html
More information about the cap-talk
mailing list