[cap-talk] How desirable / feasible is a persistent OCAP language?
erights at gmail.com
Thu Jul 17 09:32:38 CDT 2008
On Thu, Jul 17, 2008 at 3:33 AM, Rob Meijer <capibara at xs4all.nl> wrote:
> I personally feel that real persistent processes, (especially when using
> an OCAP language to create the code for these processes) would greatly
> help in reducing the complexity of least authority design, but given the
> fact that this subject to my knowledge has not been more than slightly
> touched on this list, I have no way of knowing if this personal stand on
> is one that has a general consensus, is by general consensus just
> considered clueless, or has both lots of people agreeing and disagreeing.
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.)
The previous discussions we've had on the list, and the remaining
controversies, regard how to get there. Should persistence be orthogonal or
not? Given either answer, how do you handle upgrade? <
Should it be built into the kernel/TCB (Smalltalk, Waterken, Newspeak? <
http://bracha.org/Site/Newspeak.html>), or should it be written in the
language with no undue privilege <
Next to the desirability question, a second question might be just as
> important, how feasible would it be to make one (or more) of the current
> OCAP languages into a persistent language, and if its feasible, would the
> private storage facility offered by MinorFs be sufficient to make making
> that language persistent be sufficient to make image storage completely
> adhere to POLA itself.
The key constraint that Joe-E enforces, that enables Waterken to provide
orthogonal persistence, is that Joe-E objects cannot advise their own
serialization through the Java serialization mechanism. They can interfere
with it only to the extent of preventing serialization. Should serialization
of a Joe-E graph succeed, it's guaranteed orthogonal.
Text by me above is hereby placed in the public domain
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cap-talk