<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I like the idea of having the script explicitly manage its own state, but this either means a massive divergence from how Second Life handles state, or getting a lot of changes past the Lindens. <a href="https://jira.secondlife.com/browse/SVC-966">https://jira.secondlife.com/browse/SVC-966</a> ("Script configuration object type") would be a good start for having SL-native scripts be able to store state in any useful way, at least.</div><div><br></div><div><div>On 14 Sep 2008, at 06:07, Mike Deem wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div>Perhaps scripts should be responsible for explicitly storing and fetching state as needed. That is how the vast majority of programming environments work. There is usually no expectation that a running program's state is preserved at all times. </div> <div> </div> <div>A simple get/put property bag API could be provided by the platform. Such an API could be backed by a local DB, an assert server, or even a cloud store like Amazon S3 or something.</div> <div> </div> <div>External script servers may also make load balancing easier. A single srever could handle scripts in multiple regions, or a single reagion's scripts could be spread across multiple script servers. Also, moving all script HTTP, e-mail, and RPC I/O to a different machine could help balance network load.</div> <div> </div> <div> == Mike ==</div> <div><br> </div> <div class="gmail_quote">On Sat, Sep 13, 2008 at 9:30 PM, Dahlia Trimble <span dir="ltr"><<a href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a>></span> wrote:<br> <blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"> <div dir="ltr">I'm not sure I agree, periodic state backups could preserve quite a bit of information, and machines hosting simulators can fail just as a machine hosting a script server. Not sure I agree with the delays either as the script server may even be able to do things faster since it may only have script processing to do and doesn't have to spend time processing physics or whatnot. If it was able to communicate all the changes that needed to happen in a server frame before the next frame starts then it may actually be a faster design. I guess a lot depends on how it's implemented. <div> <div></div> <div class="Wj3C7c"><br><br> <div class="gmail_quote">On Sat, Sep 13, 2008 at 4:32 AM, J Ross Nicoll <span dir="ltr"><<a target="_blank" href="mailto:jrn2005@cs.st-andrews.ac.uk">jrn2005@cs.st-andrews.ac.uk</a>></span> wrote:<br> <blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">The problem with an external script server is you're still doomed if<br>the server goes down. You need to be able to serialise state anyway or<br> the first extended powercut/hardware fault/intern looking for a kettle<br>lead will cause unspeakable chaos.<br><br>You'd also be bringing in even more delay in script response time, but<br>that's relatively minor.<br> <div><br>On 7 Sep 2008, at 15:52, Mike Deem wrote:<br><br>> I've also been thinking about things like global scripts and<br>> external script servers. External script servers would solve some of<br>> the script state serialization issues. Instead of moving a running<br> > script from one region to another, it just keeps running on it's<br>> server.<br><br></div>The University of St Andrews is a charity registered in Scotland : No<br>SC013532<br> <div> <div></div> <div><br><br><br>_______________________________________________<br>Opensim-dev mailing list<br><a target="_blank" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a target="_blank" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br> </div></div></blockquote></div><br></div></div></div><br>_______________________________________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a target="_blank" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br> <br></blockquote></div><br></div> _______________________________________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></blockquote></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>The University of St Andrews is a charity registered in Scotland : No SC013532</div><div><br></div></div></span><br class="Apple-interchange-newline"> </div><br></body></html>