Easy Scripting question - Handle Key Uniqueness

[Mollymews]

8 hours ago, Love Zhaoying said:

 a "roll your own" handle:

is an interesting problem this. Giving it some more thought

pcoding a roll-your-own I think might be doable, without overly burdening performance (given the alternatives)
 

key requestA;
string uidentA;

integer uidents;


requestA = llRequest...
uidentA = (string)(10 + (++uindents % 90));  // a longer life 1000 ... % 9000, 1000000 ... % 9000000, etc


dataserver(key id, ...)
{
   if (requestA == id)
   {
      string handle = uidentA;
 
     ... process ...
   }
}

in this method uidentA will be assigned before the dataserver event fires (code in the current scope executes first)

problem is that two or more llRequest... can be issued before dataserver event fires. Which will orphan the first request (its uidentA will have been overwritten) and also is no guarantee that the dataserver event while fire in the order requested

so we would need to buffer requestA + uidentA, and perform a lookup

as we not using lists then a string buffer

key requestA;
string uidentA;

integer uidents;


requestA = llRequest...
uidentA += (string)requestA + string)(10 + (++uidents % 90));

dataserver(key id, ...)
{
   if (requestA == id)
   {
      // lookup id in uidentA buffer
      integer pos = llSubStringIndex(uidentA, (string)id);
      if (~pos) // we are good
      {        
         // the uident for id is at pos + 36, and is 2 length
         string handle = llGetSubString(uidentA, pos + 36, pos + 37);
      
         // remove from buffer
         uidentA = llDeleteSubString(uidentA, pos, pos + 37);
      
         // we might want to prepend the uident/handle to the data here
         data = handle + data;

         ... process json handle, data ...
      }
      else // we are not good. there is no uident for id
      {
         .. deal with not good exception
      }
   }
}

this is for a single script application

if we going to have multiple scripts in our app then we can include a constant identifying each script (sub-application)

uidentA = SUB_APP + (string)(10 + (++uindents % 90));

extending this to individualising for agent. Do a one-time agent key2packed (+9 chars) on sub-application start for agent

uidentA += SUB_APP + string)(10 + (++uidents % 90)) + PackedAgent;

adjusting the buffer lookup/remove positions accordingly

 

should hardcoding SUB_APP become problematic then we can use our app uuid server to assign a APP_SUB value. Which would only need to be done once - on script start.  Our sub-application (script) thereafter managing uuid/handle assignment within its APP_SUB domain

when these hit the datastore (experience/web) then they will be uniquely identifiable by application, sub-application, transaction/handle (and agent or interactive object)

   

 

[Love Zhaoying]

8 minutes ago, Mollymews said:

is an interesting problem this. Giving it some more thought

pcoding a roll-your-own I think might be doable, without overly burdening performance (given the alternatives)
 

key requestA;
string uidentA;

integer uidents;


requestA = llRequest...
uidentA = (string)(10 + (++uindents % 90));  // a longer life 1000 ... % 9000, 1000000 ... % 9000000, etc


dataserver(key id, ...)
{
   if (requestA == id)
   {
      string handle = uidentA;
 
     ... process ...
   }
}

in this method uidentA will be assigned before the dataserver event fires (code in the current scope executes first)

problem is that two or more llRequest... can be issued before dataserver event fires. Which will orphan the first request (its uidentA will have been overwritten) and also is no guarantee that the dataserver event while fire in the order requested

so we would need to buffer requestA + uidentA, and perform a lookup

as we not using lists then a string buffer

key requestA;
string uidentA;

integer uidents;


requestA = llRequest...
uidentA += (string)requestA + string)(10 + (++uidents % 90));

dataserver(key id, ...)
{
   if (requestA == id)
   {
      // lookup id in uidentA buffer
      integer pos = llSubStringIndex(uidentA, (string)id);
      if (~pos) // we are good
      {        
         // the uident for id is at pos + 36, and is 2 length
         string handle = llGetSubString(uidentA, pos + 36, pos + 37);
      
         // remove from buffer
         uidentA = llDeleteSubString(uidentA, pos, pos + 37);
      
         // we might want to prepend the uident/handle to the data here
         data = handle + data;

         ... process json handle, data ...
      }
      else // we are not good. there is no uident for id
      {
         .. deal with not good exception
      }
   }
}

this is for a single script application

if we going to have multiple scripts in our app then we can include a constant identifying each script (sub-application)

uidentA = SUB_APP + (string)(10 + (++uindents % 90));

extending this to individualising for agent. Do a one-time agent key2packed (+9 chars) on sub-application start for agent

uidentA += SUB_APP + string)(10 + (++uidents % 90)) + PackedAgent;

adjusting the buffer lookup/remove positions accordingly

 

should hardcoding SUB_APP become problematic then we can use our app uuid server to assign a APP_SUB value. Which would only need to be done once - on script start.  Our sub-application (script) thereafter managing uuid/handle assignment within its APP_SUB domain

when these hit the datastore (experience/web) then they will be uniquely identifiable by application, sub-application, transaction/handle (and agent or interactive object)

   

 

One thought is, the unique key for the "roll your own" would be: requestor object + request parameters (user key + request details: what and parms). Two requests with that same unique key could only come from the same client object; could always add a time stamp, counter, etc. 

[Love Zhaoying]

Oh, duh - just let the client get a new GUID and use it for each call. Just like the llExperience() functions will get a new GUID for each call.

[Mollymews]

1 minute ago, Love Zhaoying said:

One thought is, the unique key for the "roll your own" would be: requestor object + request parameters (user key + request details: what and parms). Two requests with that same unique key could only come from the same client object; could always add a time stamp, counter, etc. 

yes. Use Unix time stamp + counter as the transaction/handle when we want it to persist forever

[Mollymews]

20 minutes ago, Love Zhaoying said:

Oh, duh - just let the client get a new GUID and use it for each call. Just like the llExperience() functions will get a new GUID for each call.

yes this can work as well

GUID generated in state_entry. Stuffed into local persistent store (object description) so can survive on script reset. Don't need a APP_SUB uuid server when go this way

edit ps. so altogether, persistent could go something like

APP_ID = some_constant for all scripts

subAppId = key2packed(script generated uuid);

packedAgent = key2packed(agent id);

uidentA += requestID + APP_ID + subAppId + (timestamp + fixedlengthcounter) + packedAgent

Edited July 7, 2022 by Mollymews

[PheebyKatz]

You guys made this topic on purpose, to try and get me to start posting in here again, I bet. Not falling for it.

Gahhhhh, it's like math porn~!

I better get out of this part of the forum, before I end up feeling guilty and deleting everything from my hard drive.

[Love Zhaoying]

8 minutes ago, PheebyKatz said:

You guys made this topic on purpose, to try and get me to start posting in here again, I bet. Not falling for it.

Gahhhhh, it's like math porn~!

I better get out of this part of the forum, before I end up feeling guilty and deleting everything from my hard drive.

Well, I did originally have what I hoped was a valid question!

But the maths parts..ouch!

[PheebyKatz]

3 minutes ago, Love Zhaoying said:

Well, I did originally have what I hoped was a valid question!

It was an AWESOME question. Seeing this level of nerding in here almost makes me wistful, but I swore off anything involving scripting except for providing free stuff to newbies who want to blow things up and set them on fire and learn what llSleep() does... I must keep my vow~! I must!

Edited July 8, 2022 by PheebyKatz
typo nerd