Second Life is in the business of scaling up, and being deeply cautious about enabling scripted creation of content isn’t just a good idea — it’s a good way to avoid suicide. Scale up very slowly. The next unanticipated dynamic threshold in this amazing world will find you soon enough.

(8-]

Every time you edit a notecard by hand and save your version, if nobody else has a copy of the previous version, the previous version becomes “garbage”. That is, something on the asset server to which there is no reference. How do you figure out if there is no reference? That process is called garbage collection. Because the asset server is always filling up, we go through and collect the garbage every so often, to free up the space used by assets that aren’t referred to anywhere.

The ability to create garbage notecards is right now limited by the speed of human thought and typing. Even with a delay, you can bet that some script writers would regularly be updating state in notecards (daily, hourly, whatever). Consider also that scripts tend to be in-world 24/7 (unlike, at least, most avatars), and that the number of scripts (even non-trivial scripts) in a given region usually dwarfs the number of simultaneous avatars that region can even support. This would lead to an explosion of garbage. Even if it didn’t overwhelm the asset server’s space requirements, it would overwhelm our garbage collection procedures.

At which point you may wonder why we don’t keep a reference count with each asset, such as (say) languages like Java do with their objects. Well, yes, that’s an elegant solution, but bear in mind the scale of the thing. The asset server is many tens of terrabyltes (maybe over a hundred; I don’t remember the number off of the top of my head). Tens of thousands of people are creating assets all the time, and need to be accessing those assets all the time. This leads to design issues that are entirely out of the realm of design issues that you think about for a programming language and memory management on a single system. Doing all of this is **hard**. If it weren’t, then there would be lots of companies, not just Linden Lab, that had a virtual world with the scripting and content-creation flexibility on the scale of Second Life. When you really start to think deeply about the implications of script-writeable notecard (and, believe me, when I was first in Second Life in my pre-Linden days, i was fully boggled that you couldn’t just do that), the issues become absolutely as thorny as the “company line” implies, despite the dismissal of those issues in missives such as your blog post here. The asset server is designed to be “WORM” (write once read many), because that’s the way the vast majority of assets work. (Consider texures; they are uploaded once, but downloaded a lot, as people come into a region and need the texture to see what it looks like.)

At Linden Lab, we are well aware that scripters want/need some way of having persistent data associated with objects and scripts. It’s not clear that writeable notecards are the right way to do that. Most obvious things you can come up with will have non-obvious wrinkles and issues associated with them that are unique to the nature of having a single large global virtual world like Second Life. Currently, those working on scripting are focusing on making Mono work right; you can go into Aditi (the beta server) and check out regions that are Mono enabled. We don’t want to make big changes to the LSL functions and capabilities while trying to make sure that Second Life with Mono properly runs LSL; that moving target would make it much harder to get Mono stable. After that, obviously I can make no promises, but some sort of persistent store *is* something many of us would like to see. Will it happen in the next year? Who knows?

-Prospero Linden (who came here looking for a way to do character animation in Blender, but found this….)

I’d much prefer a function with no delay over a function with a long delay; but I’d prefer a function with a long delay over having no function at all.

But as for the notecard-writing function-delay – I would have to disagree with you that it would be the best solution. The delay, in my estimation, only would cause more issues to adding data to a notecard because there is already a delay. Not only would you be stacking delays on top of delays, but you have this possibility for making scripts become backed up with requests, crashing, or breaking entirely.

Maybe the best solution is the use of objects or note cards inside of a scripted object.