[cap-talk] How desirable / feasible is a persistent OCAP language?
Karp, Alan H
alan.karp at hp.com
Tue Jul 29 11:04:31 CDT 2008
Bill Frantz wrote:
> However, I should not try to speak for Alan.
Once again showing good judgment.
There are two independent pieces that led to my questions. First, MarcS and I have been working with the Waterken server. It's a remarkable piece of software. While it's persistence model has saved us untold lines of code, we have made changes incompatible with the serialized objects, which forced us to throw away the saved state and start over. That's OK for a research prototype, but not for the real world. (OK. I admit it. I'd probably be better off if I lost my state saved by Outlook.) That experience primed me to pay attention when this thread started.
The second piece is my work on ZBAC with the Navy. In order not to step on more toes than I have to, I've been telling them that their investment in identity management and role and attribute based access control hasn't been wasted. They still need it to know what SAML authorization assertions to give people when they log in. Of course, that's a half-truth. If that's what you want to do, a c-list is more convenient, but we don't use the c-word with this crowd.
Bringing these two experiences together got me thinking about the distinction, which I believe is one of completeness. Orthogonal persistence (OP) captures the entire reference graph so that it is available on restart. The ZBAC approach is to capture only enough of the permission state to allow rebuilding of the desired part of the reference graph after a restart.
Here's an example. At the beginning of the world, an object Alice has references to objects Bob and Carol. Alice invokes Bob, passing a reference to Carol as a parameter. The system then restarts. With OP, on restart Bob has a reference to Carol. In the ZBAC approach, Bob does not unless some extra steps were taken, such as an administrator adding Bob to the ACL for Carol. (Note that ZBAC is still capabilities; the ACL is only used to determine the set of references an object gets when it starts.)
That raises some questions. Are upgrades are easier with the ZBAC approach if we include the fact that it requires an extra layer of management software? Can we make it easier to code upgradable programs with OP by only saving the relevant part of the object graph? Are there language constructs that interact with the persistence mechanism that make it easier to do upgrades? This last question is my reading of what Rob asked when he started this thread.
Virus Safe Computing Initiative
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
More information about the cap-talk