idea on prop 69, llList2Notecard: create card manually?

Prop 69 was recently marked "Can't Do". The Linden Notes (and every town hall with Cory) mentions the sensitivity regarding creating new assets. Instead of creating a new asset, would it help if the function could only use an existing (manually created) notecard?

This doesn't solve all data storage challenges, but it would solve a lot of common needs. I also like the idea of using a notecard (rather than some API-only data lump) because they are readable by humans.

More robust systems are being considered (/invalid_link.html), but they sound much more complicated, both for LL to implement, and for your average scripter to use.

Cory mentioned something in that thread I didn't quite understand, but might mean that pre-creation of notecards won't help.
If each write to the (single, manually created) notecard causes asset system load, then I would guess this idea doesn't help at all.

The following is guesswork and deduction based on some hints and tidbits I've picked up from playing in the world along with reasoning based on my technical experience... I'm not sure it's right, but I think it's close.

Basically, every time you make something in your inventory (say, a notecard), a new asset is created. That much is obvious.

What may not be obvious is that every time you change that notecard and click "save", another new asset is created. Why not just change the contents of the existing asset?

Well, that can't be done because the asset system is based on references, not concrete copies of things. Example: you create a notecard, put some text in it. A new asset is created. You send a copy to your friend. In this case, a new asset is _not_ created for your friend, they just get a "mention" (with appropriate permission information from the card's next-owner perms) in their inventory. Both of those inventory items refer to the exact same place in the database. This is a concept called "copy-on-write", and it's used in lots of places in your computer.

Why do this? Because people copy things all the time. It's far more efficient to store all the identical copies as one single asset in the database, and make modifications be entirely new objects. It's pretty much just how this kind of thing is done.

So, if you have a way for a script to "modify" a notecard, really what happens is the script is going to be creating a new notecard every time it touches the data. I can see the possibility that scripts will want to change a notecard very, very frequently, and the database would be quickly filled with new assets from all the modifications. You can't just modify the assets directly, because there's no way to know whether someone has pulled out a copy of the notecard while the script is running. If you just blindly modified it, that copy would be blindly modified too, and that'd be very confusing and simply not correct.

Basically, the asset system isn't really made to handle this kind of thing, and any attempt to make it so would just be an ugly solution prone to oversights and errors. The best solution is what they're doing: a new data system for this kind of data storage.

Hope that helps. Remember it's all speculation, but I'm pretty sure it's right.

Hm, it's a complex second world! Thanks for the thoughts.