"Linkset Data" is coming.

[Zi Ree]

10 minutes ago, Rider Linden said:

1. linkset_data is thrown even on a "trivially" successful operation. 
2. linkset_data is thrown only when there is a change to KVP data. 

 

2

[Quistess Alpha]

41 minutes ago, Rider Linden said:

Which of those two would people prefer?  

I'm also in #2 camp; I think it's easy enough to script around either case (ss long as it's well-documented) , so give preference to the one which is (trivially) less likely to overflow event buffers.

Edited October 25, 2022 by Quistess Alpha

[Frionil Fang]

1 hour ago, Rider Linden said:

2. linkset_data is thrown only when there is a change to KVP data. 

#2 sounds like the more useful and less spammy result. If someone absolutely needs to know that a linkset op that had no effect was performed, the script performing it can signal it, say, via setting "no_op_update" key to (string)(++no_op_update_count) or whatever.

[Jenwen Walpole]

2 hours ago, Rider Linden said:

I'm going to bring this up at tomorrow's user group, but I wanted to throw it out for discussion.

Right now if you update a key-value pair with an identical value ("foo:bar" and you reassign the value "bar" to the key "foo"), or when you delete a non existent key I will fire the respective event.  The logic there is that the operation was successful, even if trivially so. "bar" is now the value of "foo" and the key you deleted is not in the store.

The other school of thought is that the event should indicate a change in the KVP store. No key in the database? then no event on a delete.  If the value at a key is the same before and after then the KVP store has not changed so do not fire an event.

Which of those two would people prefer?  

1. linkset_data is thrown even on a "trivially" successful operation. 
2. linkset_data is thrown only when there is a change to KVP data. 

I am for whatever will give the better performance. If there has to be an internal read before write to acomplish not generating the event and if that read will slow down the wirte / delete performance then id rather generate the extra events if event handling is enabled.  Though i think that the scipter should have the option for not generating events in the first place for given write/delete operation (asumeng there is an event handler).

[Wulfie Reanimator]

I think I would rather have an event per change (it might make more scripts simpler), but no strong opinion yet.

I'm trying to come up with use-cases for no-op events, but the only thing I can think of is linkset-wide signals, which is already covered by llMessageLinked.

When would a script want to react to LSD updates that don't change its state?

Edited October 25, 2022 by Wulfie Reanimator

[Love Zhaoying]

13 minutes ago, Wulfie Reanimator said:

When would a script want to react to LSD updates that don't change its state?

If one link updated LSD, another link could get signaled that there was an update, without the need for an extra linked message.

[Wulfie Reanimator]

4 minutes ago, Love Zhaoying said:

If one link updated LSD, another link could get signaled that there was an update, without the need for an extra linked message.

But that's the thing; there was no update because nothing changed.

[Love Zhaoying]

1 minute ago, Wulfie Reanimator said:

But that's the thing; there was no update because nothing changed.

Ok, had to read back: "no change" meaning, an LSD KVP update resulted in no update because the KVP didn't change? Well then, if that's the case, we need to tell everyone, "HEY!! Hey hey heyyyy! One of the links tried to update this here KVP, but the value did NOT change!" Because that way, the script that needs to know can stop doing whatever it would have done if the value HAD changed. 

[Wulfie Reanimator]

1 hour ago, Love Zhaoying said:

Ok, had to read back: "no change" meaning, an LSD KVP update resulted in no update because the KVP didn't change? Well then, if that's the case, we need to tell everyone, "HEY!! Hey hey heyyyy! One of the links tried to update this here KVP, but the value did NOT change!" Because that way, the script that needs to know can stop doing whatever it would have done if the value HAD changed. 

Can you give an example?

[Love Zhaoying]

30 minutes ago, Wulfie Reanimator said:

Can you give an example?

Sure. Distributing multiple scripts into each link, they can communicate with just other scripts in the same link using llMessageLinked() with LINK_THIS, so all scripts in all links don't get the messages.
 

But, since the LSD KVP storage only applies to the entire linkset..there, they've got to potentially impact the other scripts. There's a trade-off between "lookup each KVP and only update if it's changing" vs. "Fire and forget" / "send the update regardless". 

In the middle ground, a script may not be time critical, may allow for asynchronous activity (no hurry on the reply), but you don't want the added overhead of always checking that the KVP always exists. But the script NEEDS to know if the KVP exists..because it only should do the "next task in the sequence" if the KVP changed. So..

How detailed did you want me to get?

[Wulfie Reanimator]

2 hours ago, Love Zhaoying said:

Sure. Distributing multiple scripts into each link, they can communicate with just other scripts in the same link using llMessageLinked() with LINK_THIS, so all scripts in all links don't get the messages.
 

But, since the LSD KVP storage only applies to the entire linkset..there, they've got to potentially impact the other scripts. There's a trade-off between "lookup each KVP and only update if it's changing" vs. "Fire and forget" / "send the update regardless". 

In the middle ground, a script may not be time critical, may allow for asynchronous activity (no hurry on the reply), but you don't want the added overhead of always checking that the KVP always exists. But the script NEEDS to know if the KVP exists..because it only should do the "next task in the sequence" if the KVP changed. So..

How detailed did you want me to get?

Explain it to me like I'm 5. 🙂

I guess I'm not seeing LSD as a general communication device like llMessageLinked. (I see it as data storage, as in it holds state.)

My current thinking of how the events should work is: When a key is created, other scripts are notified, and all of those scripts know the value of that key with no additional checks from that point onward.

At that point, every script in the linkset can continue to do their job because they know that value. If any other script creates or sets the same key to the same value, there should be no change in behavior necessary for any script, since they were already doing their work with the same, known value. (Right? Or this assumption not correct?)

This way the functions really are "fire and forget" in the sense that you don't have to check the current value, a new event will only happen if the function *did* something to the storage.

If the value changes or the key is deleted, that's an important state change that other scripts should be able to react to.

Edited October 25, 2022 by Wulfie Reanimator

[Kyrah Abattoir]

On 10/20/2022 at 5:52 PM, Lucia Nightfire said:

I think the argument is too one-sided.

Would you, in-turn, want other creator scripts you chose to leave intact in your objects or were unaware that existed in your objects to also delete your own protected keys as well?

There are two scenarios where this will typically be an issue:

1. Other-creator objects already containing other-creator scripts being linked together and said scripts being maintained for the sake of functionality/convenience or because the object owner lacks the skill/knowledge to achieve the same functionality with their own scripts.
2. Users directly placing other-creator, no-mod scripts in their content for the sake of functionality/convenience or because the object owner lacks the skill/knowledge to achieve the same functionality with their own scripts.

Without including delete protection, the protected keys feature is incomplete and would only lead to an increase in no-mod content, in-turn, making protected keys redundant.

There is no 100% best way to deal with it. The nuclear option of wiping all data is a "hopeful" deterrent to allow for good actors to work together in the same environment.

I get that I'm just worried of some scripters doing the whole "dog marking their territory" on the linkset datastore rather than trying to be cooperative. We have no shortage of creators with a god complex.

[Love Zhaoying]

3 hours ago, Wulfie Reanimator said:

Explain it to me like I'm 5. 🙂

I guess I'm not seeing LSD as a general communication device like llMessageLinked. (I see it as data storage, as in it holds state.)

My current thinking of how the events should work is: When a key is created, other scripts are notified, and all of those scripts know the value of that key with no additional checks from that point onward.

At that point, every script in the linkset can continue to do their job because they know that value. If any other script creates or sets the same key to the same value, there should be no change in behavior necessary for any script, since they were already doing their work with the same, known value. (Right? Or this assumption not correct?)

This way the functions really are "fire and forget" in the sense that you don't have to check the current value, a new event will only happen if the function *did* something to the storage.

If the value changes or the key is deleted, that's an important state change that other scripts should be able to react to.

Exactly! The sitchyashun I was describing is an "edge case" where you DO care if the data already exists.  And I do!

Most of the edge cases I can think of are "iffy" EXACTLY because you can do a LSD "Find" synchronously, and it is theoretically "fast".

Here's an edge case using the most recent POC I did for my WIP JSON Parser: A number guessing game.

In this edge case scenario, all the code is in one link - as the whole "harumph, different links.." curveball I threw last round was not really pertinent.

1. Assumption: The JSON data ("variables") which I stored data in, would be in LSD KVP (whether for each value, or storing a whole honkin' JSON string) - instead of  in memory.

2. User guesses a number. If the guess does not match the answer, continue with the following steps

3. Need to see if the user already guessed that number!

4. Lookup the guessed number in LSD.

5. If the user did NOT guess the number yet, add to LSD.  

6. Otherwise, if the user DID guess the number already: Tell the user "Sorry, you already guessed that number".

7. Here's where it gets hard to explain to a 5-year old:

a. The entire program is asynchronous. And re-entrant because of this.  So, no harm no foul if an asynchronous call is needed.

b. IF (here's where it gets "IFFy") there is some savings or performance or system advantage to "update and wait for async response" vs. "lookup" then this edge case would:

i. Try to "add" the guess - which already exists. Is this like an "update"? I haven't paid attention, sorry.

ii. Assuming "add" is like an "update" - and the KVP already exists - the code would use the LSDEvent() response "that KVP already existed" (what I think you call a "NOP"?) instead of the "guess lookup".

iii. If the LSDEvent() response "that key already existed" were returned, this code would follow the action in #6 above.  

iv. Yes, all this is instead of just doing a Find KVP call.

v. Yes, it only matters if the LSD Find KVP is slower than attempting to update, or expensive in some way.

..I hope that helps?  I can try again with another edge case..

But anyway, since the basic llLSD() calls are SYNCHRONOUS - and, I assume - faster than a vampire covered in ghee (or that slippery) - then it is not a perfect, need it, gottahaveit use-case.

 

 

Edited October 25, 2022 by Love Zhaoying
llLSD(), not lslLSD()

[Love Zhaoying]

39 minutes ago, Kyrah Abattoir said:

I get that I'm just worried of some scripters doing the whole "dog marking their territory" on the linkset datastore rather than trying to be cooperative. We have no shortage of creators with a god complex.

Since I am seeing these new LSD features as more of a "replacement for needing more memory" - to me, it DOES become more "critical" that nobody else (no other scripts) clear my KVP!  Otherwise, I'd have to tell users "Sorry, you cannot use any other scripts with my system if they also use LSD." ("Only 1 creator can use LSD per linkset.")

[Love Zhaoying]

12 hours ago, Rider Linden said:

Which of those two would people prefer?  

1. linkset_data is thrown even on a "trivially" successful operation. 
2. linkset_data is thrown only when there is a change to KVP data. 

If "Find" was slow (or all the calls were not synchronous), I would possibly want 1.  That way, instead of "Find" I would use "Update" and look for an update reply telling me:  did a change occur or not?

But if "Find" is fast, and since all the calls are synchronous (not REQUIRING events), I will be OK with 2 I wrote @Wulfie Reanimatora long, contrived use-case / edge case where it was hard to justify this. And I tried.

 

[Wulfie Reanimator]

3 hours ago, Love Zhaoying said:

..I hope that helps?

It does! Thanks for explaining your use-case.

[Quistess Alpha]

5 hours ago, Love Zhaoying said:

2. User guesses a number. If the guess does not match the answer, continue with the following steps

3. Need to see if the user already guessed that number!

4. Lookup the guessed number in LSD.

I kinda skimmed your scenario, but if the 'universe of guessable numbers' is small enough (less than 500?) I'd probably go with a list of bitmask integers in script memory.

[Love Zhaoying]

25 minutes ago, Quistess Alpha said:

I kinda skimmed your scenario, but if the 'universe of guessable numbers' is small enough (less than 500?) I'd probably go with a list of bitmask integers in script memory.

I use a JSON_ARRAY object now, since the entire parser is JSON-based.

ETA: There's only 1 "answer", and the user is given only 10 guesses in my current settings. So: Only need to track 10 guess with current "guess a number between 1 and 100".

If the number was between "1 and 1000", maybe give the user 20-30 guesses.  Using my own guessing strategy, could probably usually guess it.  I'm trying to "reverse-engineer" my own guessing strategy so I can "teach" the program to guess an unknown number, too.

Edited October 25, 2022 by Love Zhaoying

[Jenwen Walpole]

7 hours ago, Love Zhaoying said:

..I hope that helps?  I can try again with another edge case..

I suppose you could give just as much creedence updating a KVP with the same value just to force an event.don't get me wrong, its nice to know of a KVP changed vs just was written to and there is no change.

if you were going to do this at all, then why not have the event state if it was a new value or not.

linkset_data action constants

example:

 

LINKSETDATA_RESET    0    The linkset's datastore has been cleared by a call to llLinksetDataReset.
LINKSETDATA_WRITE    1    A key in the linkset's datastore has been assigned the same value with llLinksetDataWrite
LINKSETDATA_DELETE    2    A key in the linkset's datastore has been deleted. Either through a call to llLinksetDataDelete or llLinksetDataWrite with an empty value

LINKSETDATA_CHANGE 3  A key in the linkset's datastore has been assigned a new value with llLinksetDataWrite

 

 

(typo edits)

Edited October 25, 2022 by Jenwen Walpole

[Jenwen Walpole]

additional note / thoguht: you could also be a bitmaped response for linkset_data event action - but i suppose(and just by accedent)   1 and 3 responses above allow it to be ANDed  with a 0x01 to determining any write occured. ...  if thats an intentional thing then it sould be called in the docs with an example or just make the responses bitmaped 0x01 0x02 0x04 0x08,

bitmap might make more sense then you could have the following

LINKSETDATA_RESET    0x01    The linkset's datastore has been cleared by a call to llLinksetDataReset.
LINKSETDATA_WRITE    0x02    A key in the linkset's datastore has been wiritten to llLinksetDataWrite
LINKSETDATA_DELETE    0x04    A key in the linkset's datastore has been deleted. Either through a call to llLinksetDataDelete or llLinksetDataWrite with an empty value

LINKSETDATA_CHANGE 0x08  A key in the linkset's datastore has been assigned a new value with llLinksetDataWrite

where on a change both LINKSETDATA_WRITE and LINKSETDATA_CHANGE bits would be set.  and if it was written to but not changed only the LINKSETDATA_WRITE would be set.  

this way a simple 'AND' in your event logic can filter for whatever you want.

seeing as your most likely filtering your event anyway...

(edits for typoo's)

 

Edited October 25, 2022 by Jenwen Walpole

[Gabriele Graves]

6 hours ago, Love Zhaoying said:

Since I am seeing these new LSD features as more of a "replacement for needing more memory"

QFT and funny!

[Tapple Gao]

18 hours ago, Rider Linden said:

Which of those two would people prefer?  

1. linkset_data is thrown even on a "trivially" successful operation. 
2. linkset_data is thrown only when there is a change to KVP data. 

I prefer #2. I created a jira about it also: https://jira.secondlife.com/browse/BUG-232795

[Gabriele Graves]

18 hours ago, Rider Linden said:

Which of those two would people prefer?  

1. linkset_data is thrown even on a "trivially" successful operation. 
2. linkset_data is thrown only when there is a change to KVP data. 

I vote for 2.

[Jenwen Walpole]

19 hours ago, Rider Linden said:

.

1. linkset_data is thrown even on a "trivially" successful operation. 
2. linkset_data is thrown only when there is a change to KVP data. 

I vote 1 and 2 - see details in my earlier message on linkset_data action codes.

[Rider Linden]

*ATTENTION*

I gave llLinksetDataDelete and llLinksetDataDeleteProtected a return code so that you can know if they fail.  Unfortunately this means you will need to resave any script that uses those two functions.

(*this is why we never change functions in production.)