LinksetData aand Script Sharing Awareness

[Lillani Lowell]

I wanted to start an additional thread on this, because I think it's an important topic.

As someone who is building new, plug-in systems for items (like my Action Engine which is getting a linkset data update) I kind of want to give an overview of how I am treating linkset Data. When it comes to content creation, we often don't know what other scripts/plugins/etc will be included in our items-- we don't know what things we have to share resources with. So, being aware of your own Linkset Data usage and how it may interact with other people's usage is very important.

In self-contained, no-mod items it's not really a worry... but in things like furniture, attachments, houses, etc, there are some serious things to take into consideration because Linkset Data is global.

Here's my self-imposed rules for being a better contributer to the global eco-sphere and making my own scripting life easier in the long run:

1. Never use llLinksetDataReset(). This could, in many ways, break products you cannot foresee how people are using... or what scripts may be sharing your use of Linkset Data. You can't predict what plugins, modifications, or whathave you people are doing with your product. In a world of custom content, telling people "they can't" is bad form... so, if they can't, make your object no-mod, and be done with it.

2. Use your own, personalized identifiers... it might be nice to easily reference a entry called "uuid", but someone else's three other scripts could also be using that entry for other things. So, I will always be using unique identifiers in front of my keys like (example) "_dictLLEnt_uuid"; this makes the likelihood of someone else over-writing my uuid entry for something entirely different and unrelated much more unlikely. 

3. Keep track of the keys you use, and delete them when you're not using them. If you are using personal identifiers like I do, to easily clean up your own script's keys you can then easily have a little function that looks up any key with your unique identier. For instance, all I need to do is find all my keys starting with something like "_dictLLEnt_" and delete them all instead of keeping track of each one, or using a linkset data reset. It helps keep the Linkset Data clean without having to a data reset. This will save you and others a lot of future headaches when Linkset data is shared across scripts. I mean, do you want your reset to break someone's product because of another script's use of the data? Nah, you don't want that on your hands. So, clean up after yourself, it's only polite. 

4. Don't hog the linkset data. I know it's great to use new and shiny tools, but only use as much as you actually need. If you're not running into memory issues, or it's not reset critical. Why not keep it out of the linkset data? There's no need to keep owner uuids in a linkset... that's built into LSL, etc. Don't use it as a database to store a lot, or large objects if you ever expect your scripts to play nice with other scripts... sharing is caring. I know there's probably people wanting to build furniture engines using that; and I can give you 20 different reasons why it's a really bad idea from the start.

Anyway, these are my own personal rules, but I thought others might take some wisdom from the perspective.

And please feel free to add to this, if you feel there's something useful you can add to the shared use of linkset data to make all our lives a little easier with this shared object resource.

 

 

[Rolig Loon]

These make sense. It's tempting to start using LinksetData as a dumping ground for all sorts of information. I suspect that many scripters will start doing that, forgetting that other people may eventually be using the same space. It's dangerous to leave your own data vulnerable and it's thoughtless to deny other scripts access to the storage space unnecessarily. The best way to minimize either problem is to develop some best practice guidelines. There's no way to enforce them, of course, but if scripters are at least aware of the concerns, they will be using LinksetData with their eyes wide open.

Your fourth guideline is the one that I suspect will be neglected most often.  LinksetData has a capacity of 64k, which sounds like a lot until you think of how rapidly a simple greeter script, for example, might fill up the space with UUIDs if they weren't saved judiciously and erased quickly.

[Wulfie Reanimator]

Another thing to consider is how your script could be written to not rely on LinkSet Data. LSD is a convenient cache so your script doesn't have to spend time doing extra work, but if the value is not there (or it cannot be written because there's not enough space), your script should have some way to generate that info from scratch. (Assuming it's not a multi-script system, but even then, good to design a backup.)