[cap-talk] How desirable / feasible is a persistent OCAP language?

[James A. Donald]

Mark Miller writes:
 > Hi Rob, my sense is that there is a general consensus
 > that ocap languages should be made persistent. (This
 > is of course a great opportunity for those who dissent
 > from that consensus to speak up.)

I wish those that want to make object capability languages
persistent luck - for I think they will need it.

Rephrasing what I posted previously:  Persistence is
hard, and is apt to get you into trouble when one needs
to update and change what is persistent.  Object
capabilities become interesting and important on
distributed systems, on networks, and distributed update
is an enormous problem, not yet fully understood.  When
complications due to persistence intertwine with
complications due to distributed data and distributed
update, we get in really deep trouble.

Obviously if we want to do absolutely everything with
capabilities and nothing with access control lists, we
need persistent objects.  To me, this is an argument
that trying to do absolutely everything with with
capabilities is apt to become alarmingly complicated,
that capabilities are better suited for transient
permissions, such as the implicit permission that a user
gives a word processor to write to a file, or the
permission a web server gives a script from another
server to write to a browser window, but many people on
this list disagree very strongly with that view.

In computer science, we run into a lot of debates of the
form

     "X is easy, X is a solved problem, we just have to
     apply the well known, well studied, and working
     protocol Y for X, which protocol has been
     incorporated in the well known public domain library
     ZZZ"

     "X is hard, and Y for X does not really work, at
     least not by itself"

     "What!  Of course Y for X works!  We have a proof it
     works.  Present your example that it fails, and you
     will be famous!"

     "Consider the very common situation .....  then
     disaster ensues, and indeed this happens all the
     time in the existing product so and so that uses Y
     for X.

     "That is not an example of Y for X failing! That is
     some code or person that uses Y for X failing!"

In such debates, I am usually the one saying X is hard,
and Y for X fails.  Over the years I have deprecated a
great many Xs and Ys for X.  Sometimes, probably most of
the time, a solution for X eventually appeared, but it
always took longer and cost more.