<div dir="ltr">On Thu, Jul 17, 2008 at 3:33 AM, Rob Meijer <<a href="mailto:capibara@xs4all.nl">capibara@xs4all.nl</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I personally feel that real persistent processes, (especially when using<br>
an OCAP language to create the code for these processes) would greatly<br>
help in reducing the complexity of least authority design, but given the<br>
fact that this subject to my knowledge has not been more than slightly<br>
touched on this list, I have no way of knowing if this personal stand on<br>
is one that has a general consensus, is by general consensus just<br>
considered clueless, or has both lots of people agreeing and disagreeing.</blockquote><div> <br>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.)<br>
<br>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? <<a href="http://www.erights.org/data/serial/jhu-paper/upgrade.html">http://www.erights.org/data/serial/jhu-paper/upgrade.html</a>><br>
<<a href="http://waterken.sourceforge.net/upgrade/">http://waterken.sourceforge.net/upgrade/</a>><br><br>Should it be built into the kernel/TCB (Smalltalk, Waterken, Newspeak? <<a href="http://bracha.org/Site/Newspeak.html">http://bracha.org/Site/Newspeak.html</a>>), or should it be written in the language with no undue privilege <<a href="http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual_Suspicion">http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual_Suspicion</a>>?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Next to the desirability question, a second question might be just as<br>
important, how feasible would it be to make one (or more) of the current<br>
OCAP languages into a persistent language, and if its feasible, would the<br>
private storage facility offered by MinorFs be sufficient to make making<br>
that language persistent be sufficient to make image storage completely<br>
adhere to POLA itself.<br>
</blockquote><div><br> </div></div>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. <br clear="all">
<br>-- <br>Text by me above is hereby placed in the public domain<br><br> Cheers,<br> --MarkM<br>
</div>