Journey Bunny
I found a request for llLinksetDataWritePublic; I'm requesting something similar but distinctly different, hoping this will be compatible with what we have now.
I'd like to request a variant of the linkset data functions with the word Remote, and a pin parameter. This set of functions would permit scripts in objects to get or set the linkset data in other objects via a secret access pin when the prim is set to Mod.
There's precedent for this! We have remote script pin, for starting/stopping/replacing scripts in other objects. I propose we do the same for data.
(I'll bold the new functions & events, the rest work like their current counterparts)
Function Spec:
  • function
    integer llSetRemoteLinksetDataPin(integer pin)
Allows a prim to have scripts remotely get and set linkset data
  • function
    integer llLockRemoteLinksetDataPin(integer pin, integer Locked)
Allows a prim to be set to
prevent
linkset data access from being granted via pin, using a different pin. Eg, a creator could use a pin to set lock to TRUE, preventing a customer from enabling remote data access with a Mod prim.
  • integer llLinksetDataRemoteWrite( key target, integer pin, string name, string value);
  • string llLinksetDataRemoteRead( key target, integer pin, string name);
  • integer llLinksetDataRemoteDelete( key target, integer pin, string name );
  • list llLinksetDataRemoteDeleteFound( key target, integer pin, string pattern, string pass );
  • llLinksetDataRemoteReset( key target, integer pin );
  • integer llLinksetDataRemoteAvailable( key target, integer pin );
  • integer llLinksetDataRemoteCountKeys( key target, integer pin );
  • integer llLinksetDataRemoteCountFound( key target, integer pin, string pattern );
  • list llLinksetDataRemoteListKeys( key target, integer pin, integer first, integer count );
  • list llLinksetDataRemoteFindKeys( key target, integer pin, string regex, integer first, integer count );
Read, Write, and Delete functions traditionally have a *Protected variation that works the same but adds a string password. This spec could extend protected functionality as well, or we could choose to implement just the functions above to alow data that is "already public."
Events Spec:
Minimal spec, using existing event:
linkset_data( integer action, string name, string value )
Gains the following constants:
  • LINKSET_DATA_REMOTE_RESET | The remote linkset's datastore has been cleared by a call to llLinksetDataRemoteReset.
  • LINKSETDATA_REMOTE_DELETE | A key in the remote linkset's datastore has been deleted. Either through a call to llLinksetDataRemoteDelete or llLinksetDataRemoteWrite with an empty value
  • LINKSETDATA_REMOTE_MULTIDELETE | A comma separated list of the keys in the remote linkset's datastore which have been deleted through a call to llLinksetDataRemoteDeleteFound.
Maximal spec, using a new event:
  • function
    integer linkset_data_listen( key target, integer pin ) | Fires a linkset_data_remote when the remote linkset data changes. Returns handle
  • function
    linkset_data_close( integer handle ) | No longer fires an event when a remote linkset changes.
  • Event
    linkset_data_remote( key linkset, integer action, string name, string value ) | Receives all linkset data events from the remote object as though it were that object itself.
I see a minimal event spec as being useful and easier to implement; it essentially just tracks when successful
remote
linkset operations instigated by
this
script have completed. This provides the minimal needed feedback, and the script would need to check remote data when it intends to use it.
The maximal spec might generate a lot of events between objects. But, it's nothing we're not already doing, more clumsily, with the messaging system, but this way would be much cleaner.
With a dedicated listen/event event, we could properly have a multi-object game using common data, with events and functions fired by remote trigger. A real game platform!
One consideration: It might be desirable to have mod objects, without allowing third-party control. I have included a function to lock/unlock pin access for this purpose.