[cap-talk] Terminology and soap box

[Jed at Webstart]

<for a brief overview, skip to <Main Focus ->>

At 03:22 AM 8/9/2006, Ian G wrote:
>...
>I'd declare capabilities to be OO

I agree.  I would say that at their best capabilities
are OO and at it's best OO is capabilities.  The
main difference that I see in practice is one of
level.  OO is generally implemented, discussed,
etc. at the language level.  There is "capability"
activity at the language level now also.  I think there
your statement that capabilities = OO is especially
true, to me anyway.  The "capability" aspect to me
seems to merely focus on the communication of
object permissions (references) - delegation.

Generally I think the focus for past capability systems
have been at an inter process communication level.
Namely at a level where permission tokens (capabilities)
can be sent in messages between processes (active
objects).  In that regard I agree with my sense of your:

>perhaps with a stress that it works across a net.

In answer to David Hopwood's:

At 08:47 AM 8/9/2006, David Hopwood wrote:
>Cap systems do not necessarily work across a net. Please don't confuse
>whether it is *desirable* for a cap system to work across a network
>(partial network transparency), with whether this is part of the concept
>of a capability system.

I'm not sure how much of the above disagreement with Ian is real and
how much is terminology.  As I noted above I think there has been
an emphasis (perhaps mostly in the past) in capability systems for
IPC - namely messages between processes, domains, active objects,
actors, whatever you want to call the environment of an executing
program.  This is distinct from the language level where the OO
concepts reign supreme.  Doing capabilities at the language level
is an interesting mixture where I do think they share so much in
common with OO that they can be considered the same. For those
of you who disagree, please wait until I frame a context for disagreement
more generally below.

More generally regarding David's statement:

At 08:47 AM 8/9/2006, David Hopwood wrote:
>Cap systems do not necessarily work across a net. Please don't confuse
>whether it is *desirable* for a cap system to work across a network
>(partial network transparency), with whether this is part of the concept
>of a capability system.

I ask, why don't all capability systems work across a network?
In fact you can have language capability systems that don't work across
IPC and IPC capability systems that don't extend to a network.  You
sometimes have IPC capability systems that can extend to a network,
but if so extended they so constrain the network communication model
that they are (or would be) quite useless.  I see such properties that
I consider failures to be failures to support the insertion property (to go
back to the earliest references), the inability to support a general proxy in
terminology common to this list.

On the other hand, network capability systems typically (always?) work just
fine at the IPC and language levels.   In OO language systems network
capabilities can show up as just another object.

I state my opinions on the above to try to focus attention on just what
it is that divides capability (or OO for that matter) implementations
(back on my soap box).  Let's take a high level network capability
implementation, e.g. Tyler's YURLs to be specific, and try to list
areas where they can be considered insufficient for use at the
OS/IPC or language levels.

1.  One obvious issue is performance.  YURLs are rather large blocks of
bits, and the checking at the server requires cryptographic operations.

I grant the above.  I'd like to factor performance issues out of the
discussion and focus on functionality.  I generally think that performance
issues can be effectively dealt with using caching and such techniques.
E.g. at the language level a method can make an object available whose
only function is to "invoke" the YURL.  So I then ask, in what areas of
functionality would YURLs be inadequate as capabilities at the OS/IPC
and/or language levels?

One area of concern that I can anticipate is confinement.  I argue
that confinement isn't really a part of the capability implementation
so much as it is part of the process/active object implementation.
One must ask how processes/active objects obtain permissions
to communicate.  Bundled and open or granted in some POLA
means?  I can easily imagine a "process" architecture where
permission to communicate is granted only through YURLs
(or something like them - e.g. their optimized language level
objects).  Of course you have to ask how the implementation of
an "invoke" call knows whether a YURL is valid or made up - particularly
the network address.  I believe this could be handled, but in any case
at this point I'd like to consider that an "implementation detail".
If there is no means to limit communication in a process architecture,
then no help from capability standards or methods will suffice to
add confinement.  Despite any success or failure of a process
architecture to support confinement, I argue that the capability
concept and mechanisms can add value for communication permissions
on a POLA basis - at least for adding authority to any irreducible base.

<Main Focus for this message ->

So for this exercise I would like to see enumerated the properties
that would make YURLs inadequate at the language and OS/IPC
levels if performance is ignored and confinement is assumed to
be through valid YURLs only.

I don't know of any such inadequacies, so I'll be interested to
hear about them from others and possibly to characterize them.


Regarding:

At 03:22 AM 8/9/2006, Ian G wrote:
>Jed, I wonder if you are too steeped in the inside
>minutae to see that the list is not aimed at you,
>but at me -- the external engineer, trying to figure
>out what is caps and what not?

Hmmm.  While this cap-talk list may be helpful
for you the external engineer, I think it goes to
far to say that's where it's "aim"ed.  There's certainly
lots (!) of discussion that to me seems more like
capability minutia that are of most interest to
capability practitioners debating fine points of
semantics or implementations.

>For me, the list
>works, and I wouldn't take anything out.

Good.  I'm glad it's working for you!  I certainly don't intend
to "take anything out" - though some may feel I add too much ;-)

> > OK, here's my soap box appeal:
> >
> > Join me my brothers!  Capability systems of the world, Unite!!
>...
>Here's my soap box response:  capabilities is indistinguishable
>from the concepts (not the practice) of object orientation.

I agree (particularly with regard to accommodating and not fighting),
so I revise:

Join me my brothers!  Capability practitioners and object oriented
practitioners of the world, Unite!!  Together we can redefine the
world in our image!  Together we can lead the world out of confused
separations of designation and authorization to a better world of
extendable and adaptable implementations and POLA!
Let us join together in a common alliance across all languages,
across all systems, across all networks!  Let us join with our capability
and object oriented brethren in language, OS, and network standards
to spread object capabilities to the darkest and most confused
non-POLA corners of our computing universe!  Let us bind
together designation and authorization and insure that there will
never again be failed and confused efforts to block delegation
of permission across communication channels!  Together we
can do it.  United we stand, divided we fall!

(tongue in cheek of course, though the motivation is sincere)

>In the grand scheme of things, instead of trying to fight it,
>why not try and accommodate it?  That is, move to take over the
>OO beast from inside.

I agree completely.  A "capability" is merely a communicable
permission to an object.  Indistinguishable in most ways (all
ways?) from an object reference at the language level.  My effort
is to unite across levels.  I'm not sure I would use the word
"accommodate" because it somehow smacks of compromise
and suggests that important values are going to be lost in
this effort.  That's why I want to see the list I asked for above.
I want to see just what any such lost values are.

>Otherwise, I would make the observation that after many years
>of looking and listening and arguing, capabilities has failed
>to distinguish itself in any meaningful sense from OO, to my
>mind at least.

It seems we agree there, and I would say I qualify as one of
the most focused and steeped of capability practitioners,
though perhaps not with some purity that others espouse.
I would like to clearly describe what any sort of such purity
adds that might stand in the way of uniting object and permission
to object (capability/reference) concepts from the language to
the network level.

Can anyone help me to start a list?

--Jed http://www.webstart.com/jed/