"Linkset Data" is coming.

[Lucia Nightfire]

So something I never expected would come is coming soon.

"Linkset Data"

This is dedicated memory with synchronous read/write capability in KVP form factor, currently with a 64KiB allotment for the whole linkset object.

New functions:

llLinksetDataAvailable() - Read amount of memory available.
llLinksetDataCountKeys() - Read number of keys used.
llLinksetDataRead() - Read key value data.
llLinksetDataWrite() - Create/Update key value data.
llLinksetDataDelete() - Delete key value data.
llLinksetDataReset() - Delete all keys.
llLinksetDataListKeys() - List all keys in a range.
llLinksetDataFindKeys() - Find keys by name in a range.

New event:

linkset_data(integer event, string KeyName, string KeyValue)

This event is mainly for accounting feedback purposes as all functions are actually synchronous.
You don't "have" to include this event for functionality.

new constants (returned with the event field in linkset_data()):

LINKSETDATA_UPDATE
LINKSETDATA_DELETE
LINKSETDATA_RESET

There are a dozen feature requests for something like this over the years with the most recently accepted request being https://jira.secondlife.com/browse/BUG-37766

Thoughts?

[Love Zhaoying]

Finally, won't have to squeeze data into the object description, or use equivalent hacks. This solves a long-standing need!

I foresee a primary use to save HUD data, so that the data is persistent even if scripts in the HUD are reset (without need for storing the data externally, etc.)

Personally, I would have used this years ago to store prim state details for rezzed scenes. (Position / rotation / texture offset, texture animation, etc.)

[Qie Niangao]

Very interesting. Not sure if there's any official docs for this, so I'm just going from this description: This would seem to be accessible only locally to the linkset, right? So a script couldn't perform some llGOD()-like function to retrieve another object's Linkset Data?

(If so, that's nice for stuff that needs to be secret but means we're still stuck with the same variety of kludgy, expensive, or special-case operations to share data among objects, even on the same region.)

1 hour ago, Lucia Nightfire said:

This event is mainly for accounting feedback purposes

It's also a way to pass 64k of KVP among scripts in the linkset, right? That's seems tidier (and roomier) than a bunch of link messages. (OMG. I think I have an immediate use for this to unwind a month of hideous kludge-mongering.)

Any hint if there's a limit on key count pending or can we count on total space remaining the limit? (At first glance, it doesn't seem the rationale for the upcoming change of limits to Experience KVP would apply here.)

[Fluffy Sharkfin]

5 minutes ago, Qie Niangao said:

So a script couldn't perform some llGOD()-like function to retrieve another object's Linkset Data?

Personally I'm a little curious as to how this will work with functions like llCreateLink and llBreakLink, i.e. will llCreateLink attempt to merge existing data from both objects and similarly will llBreakLink clone the data from its parent?

[Love Zhaoying]

Interesting.. if the "linkset" has a unique UUID that is used for the data, I suppose it is implied that either a) if you change any link (add/remove), the data is lost or, b) the data is associated with the root?

In the old use-case I mentioned, the linksets were "stable".

How does this, or would it, apply to linksets where there are avatars seated as part of the linkset? Would they be treated as a "temporary" link and not affect the data?

[Fluffy Sharkfin]

2 minutes ago, Love Zhaoying said:

How does this, or would it, apply to linksets where there are avatars seated as part of the linkset? Would they be treated as a "temporary" link and not affect the data?

And will sitting on random objects cause angry scripters to come running out of their houses with pitchforks screaming "GET OFF MY PRIMS! YOU BE STEALING ALL MY DATAS!!"?

[Love Zhaoying]

2 minutes ago, Fluffy Sharkfin said:

And will sitting on random objects cause angry scripters to come running out of their houses with pitchforks screaming "GET OFF MY PRIMS! YOU BE STEALING ALL MY DATAS!!"?

Hmm! I assume that only prims with appropriate rights will let anyone get the link data.

[Fluffy Sharkfin]

2 minutes ago, Love Zhaoying said:

Hmm! I assume that only prims with appropriate rights will let anyone get the link data.

I'd imagine that, as you said in your previous post, seated avatars won't have access to the data within the object they're sitting on... but the imagery amused me none the less.  

[Love Zhaoying]

You never know, if LL thought of these "obvious" things!

[Fenix Eldritch]

This is very exciting news - especially the part about the read/write being synchronous!

My guess is that it would be associated with the root: so as long as the linkset's root remains in place, the "data" is maintained.

As far as security goes, I suspect there won't be many issues from simply sitting on the object. Because even though the avatar is considered a linked "prim", the avatar itself doesn't contain scripts that could be used to access this data. Worn attachments can't access link stuff for objects the avatar is sitting on (without explicit framework), so I think there is a pretty clear boundary. At most, an attachment would just be able to see its own link data.

Edited October 10, 2022 by Fenix Eldritch

[Fenix Eldritch]

2 hours ago, Lucia Nightfire said:

New event:

linkset_data(integer event, string KeyName, string KeyValue)

This event is mainly for accounting feedback purposes as all functions are actually synchronous.
You don't "have" to include this event for functionality.

new constants (returned with the event field in linkset_data()):

LINKSETDATA_UPDATE
LINKSETDATA_DELETE
LINKSETDATA_RESET

Would it make sense to also include the link number in the event header for whatever child link raised the event?

[Love Zhaoying]

Assuming all functions apply to the entire linkset - (unless a Key in a KVP indicates a specific link - but that would be scripter determined): would the linkset data only get trashed if the Root is changed? If correct: Would the user get a Build mode warning when changing the Root, that data would be lost?

[Wulfie Reanimator]

@Lucia Nightfire Where did you get that list of functions/events? Is there more information?

[Fenix Eldritch]

Oooh, so the functions are live on the beta grid right now. I've been experimenting and here's what I'm seeing so far:

The size limits for key and value are pretty large - possibly non existent. I had a key size of 4095 bytes and a value size of 20479 bytes before I moved on to other stuff.

Also, the data stores appear to be merged when linking multiple ones together, and all others are cleared when de-linking. Here's my setup for that test:

1. created 3 prims, 2 of which had a script that created a unique KVP.
2. linked all 3 together and found the new data store contained both KVPs from step1
3. unlinked everything and the old root retained the data store, but the other scripted child prim was empty.

ETA: in the case of a key collision when merging two stores together, it looks like the link that will become the root gets priority and it will overwrite any KVPs with duplicate keys.

Edited October 10, 2022 by Fenix Eldritch

[Love Zhaoying]

30 minutes ago, Fenix Eldritch said:

Oooh, so the functions are live on the beta grid right now. I've been experimenting and here's what I'm seeing so far:

The size limits for key and value are pretty large - possibly non existent. I had a key size of 4095 bytes and a value size of 20479 bytes before I moved on to other stuff.

Also, the data stores appear to be merged when linking multiple ones together, and all others are cleared when de-linking. Here's my setup for that test:

1. created 3 prims, 2 of which had a script that created a unique KVP.
2. linked all 3 together and found the new data store contained both KVPs from step1
3. unlinked everything and the old root retained the data store, but the other scripted child prim was empty.

ETA: in the case of a key collision when merging two stores together, it looks like the linkset that will become the root gets priority and it will overwrite any KVPs with duplicate keys.

Nice that the data store wasn't lost completely on unlinking.

[Wulfie Reanimator]

32 minutes ago, Fenix Eldritch said:

Oooh, so the functions are live on the beta grid right now. I've been experimenting and here's what I'm seeing so far:

The size limits for key and value are pretty large - possibly non existent. I had a key size of 4095 bytes and a value size of 20479 bytes before I moved on to other stuff.

Also, the data stores appear to be merged when linking multiple ones together, and all others are cleared when de-linking. Here's my setup for that test:

1. created 3 prims, 2 of which had a script that created a unique KVP.
2. linked all 3 together and found the new data store contained both KVPs from step1
3. unlinked everything and the old root retained the data store, but the other scripted child prim was empty.

ETA: in the case of a key collision when merging two stores together, it looks like the linkset that will become the root gets priority and it will overwrite any KVPs with duplicate keys.

And what happens if there's not enough space to hold the data of both linksets combined?

[Coffee Pancake]

4 hours ago, Lucia Nightfire said:

Thoughts?

Networked in SL data storage here we come !!

If your datacenter looks like a datacenter, you're doing it wrong.

[Love Zhaoying]

This will actually solve some problems on the big project I'm working on. Won't need to "save state" using either a) messages to a box on my land that uses Experience functions, or b) HTTP to an external service.

Yay.

[Quistess Alpha]

Hmm, this is awesome, but does it fix the "My HUD lost all my data after I crashed and region crossed" problem? If it does, it might immediately make a kludgy fix I made for a project immediately outdated. . .

Unless all copies of "the same" object get access to the same data store (or the backend of the store is separate from the specific simulator you're on), it probably won't so my kludge will probably still be relevant . . .

[Fenix Eldritch]

28 minutes ago, Wulfie Reanimator said:

And what happens if there's not enough space to hold the data of both linksets combined?

Looks like it tries to combine them, but silently drops whatever won't fit. As before, the prim that will become the root gets priority. Interestingly, the combining seems to be done from the end of the data stores resulting in the earlier entries of the other stores getting dropped... here's my setup:

1. two prims, each with a script to create 5 KVPs. Each KVP has a 1 character key and 10k of data
   1. prim1 has keys: 1,2,3,4,5
   2. prim2 has keys: 7,8,9,a,b
2. linking them together shows that the resulting data store has keys 1,2,3,4,5,b

Of the second prim's data store, only the last entry "b" got added to the new store.

ETA: Trying the above again, but with each data store creating one less 10k KVP (so prim1 has keys 1,2,3,4 and prim2 has keys 7,8,9,a. Similar results, the new combined data store will have keys 1,2,3,4,9,a

Edited October 9, 2022 by Fenix Eldritch

[Fenix Eldritch]

Also, small update on key/value size limits. I'm fairly sure there aren't any at present. So long as you stay within the 64KB store size and don't cause a stack-heap collision, you're seemingly fine. I was able to create a single KVP with either the key or the value at 30k and it worked. I was increasing the test string by 1024 each time and after 30K, I got a stack-heap collision. So I think that's close enough.

Edited October 10, 2022 by Fenix Eldritch

[Love Zhaoying]

18 minutes ago, Quistess Alpha said:

Unless all copies of "the same" object get access to the same data store (or the backend of the store is separate from the specific simulator you're on), it probably won't so my kludge will probably still be relevant . . .

I assume the linkset data is associated with the UUID of the linkset. Assuming things is fun! Maybe I should buy a lottery ticket!

[Wulfie Reanimator]

20 minutes ago, Fenix Eldritch said:

1. two prims, each with a script to create 5 KVPs. Each KVP has a 1 character key and 10k of data
   1. prim1 has keys: 1,2,3,4,5
   2. prim2 has keys: 7,8,9,a,b
2. linking them together shows that the resulting data store has keys 1,2,3,4,5,b

Of the second prim's data store, only the last entry "b" got added to the new store.

ETA: Trying the above again, but with each data store creating one less 10k KVP (so prim1 has keys 1,2,3,4 and prim2 has keys 7,8,9,a. Similar results, the new combined data store will have keys 1,2,3,4,9,a

Oh I'm not a fan of that. I wonder why that's the behavior.

[Love Zhaoying]

1 hour ago, Wulfie Reanimator said:

Oh I'm not a fan of that. I wonder why that's the behavior.

Maybe linking different breedables can exchange "DNA" information this way. 

I betcha someone does that.

Edited October 9, 2022 by Love Zhaoying

[Lucia Nightfire]

2 hours ago, Wulfie Reanimator said:

@Lucia Nightfire Where did you get that list of functions/events? Is there more information?

I check for new functions/constants/events all the time on aditi whenever I see a new region version.

This isn't "official" yet as there are no wiki pages, nor did any Linden say it was being worked on.