[cap-talk] How desirable / feasible is a persistent OCAP language?
James A. Donald
jamesd at echeque.com
Tue Jul 22 04:38:44 CDT 2008
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
"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
"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
"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.
More information about the cap-talk