Add an agent data store for experiences
Charlotte Holmeforth
I'd like to suggest a per avatar data store for experiences. The agent data store would belong to each agent, but would be used by experience scripts to store agent data.
The data would only be accessible to scripts in objects owned by the avatar and in the same experience. For example, an attached experience HUD or weapon. Other scripts would only be able to access the data indirectly via a script that has access.
This would make experience data more scalable. The avatar's data would only be accessible if the avatar visits the experience. The experience data store wouldnt grow if more people join. For grid wide experiences, any avatar data could go in the avatar data store.
It could make per agent data more secure. For example, you could store visitor tracking info or scores so only the avatar concerned can access their data. Personal data wouldnt be accessible to anyone who can read the experience data store.
If an avatar left the experience the agent data could be automatically deleted from their data store.
There would be new functions similar to the existing experience data functions:
llCreateKeyValueAgent
llDeleteKeyValueAgent
llReadKeyValueAgent
llUpdateKeyValueAgent
llKeysKeyValueAgent
llKeyCountKeyValueAgent
llDataSizeKeyValueAgent
This shouldnt increase data storage overall, as the data would otherwise be in the experience data store. There can be a limit to how much data an experience can use, it doesnt have to be a whole notecard's worth.
Log In
Agath Littlepaws
I don't understand why it must/should be specific to experience.
I'm submitting a vote because that would really be something great, but I would find even better a system that is based on linkset data, i.e. Syncron can be called up in scripts but not limited to the linkset but can be retrieved from any object that belongs to someone.
This would also mean developers who want grid-wide data but have always had a hard time so far because they a: do not want/cannot use the email function and b: do not have their own external web server for transmitting HTTP connection information.
In contrast to linkset data sets, you would have to rethink something like clear etc. and z.b. do it in such a way that password-protected key/value pairs can only be changed with the respective password.
In order to misuse scripts that fill everything, you might then have to make it possible to delete and view all stored values directly via IEWER.
Perhaps now that I'm thinking about the potential for misuse, experience would be worth considering... however, this would mean that anyone who once had a month of Premium and thus has an experience would receive a lot of memory for every agent that ever existed... In principle, however, I like the idea that there should be agent-bound data sets... for the reasons mentioned above.
Peter Stindberg
I get the scaling argument (even though I imagine it would be more complicated on the backend, and potentially exploding the amount of data stored), especially as I heard of popular experiences running out of space.
Could you please elaborate a bit more about "It could make per agent data more secure. " - where is there a security risk in the current system?
Charlotte Holmeforth
Peter Stindberg it's bound to be more complicated, but LL are good at complicated.
In the current system if i track visitors all the visitor data goes in my backend data where i can see it (experience data store or external data). Anyone else who can access those can see every visitor, and i have to clean it every now and again to remove old data.
If there was a per avatar store, it would be similar to cookies for a web page. The experience doesnt need to store data in experience data, and can't read your data unless you visit. The only avatar data in the experience data store would be aggregate stats like visitor counts.
Looking up experience data in the avatar data store should be faster than looking up avatar data in the experience data store, as experiences have more avatars than avatars have experiences.
It would be like giving each avatar a private invisible notecard that the experience can access while the avatar is visiting. The experience would have a limit to how much data it can add, and possibly an expiry date just like cookies. You could give people experience tools to delete any agent data they dont need any more.
I think you would only put data in the agent store if you dont want it in the experience data store, so hopefully no data would get duplicated.
A use case would be a game, you give the user a hud, it tracks their progress and puts it in the agent store, next time they come they get a hud and carry on where they left off. In the mean time, the data isnt in the experience data store, and if they never come back or leave the experience it doesnt need to be cleaned up.
Another use case would be visitor tracking. We'd have the option to store info in the agent store and use it on their next visit, without knowing who visited or when or what they did. You can still give each visitor a unique experience when they return. "Hi, DisplayName! Your last visit was 2343 days ago.. would you like to teleport to the place where you left?"
Another possibility is for grid wide experiences.. imagine someone writes AvSitter Strikes Back - it could store your avatar preferences in your data store, so it knows your saved preferences and can use those on any seat.
I hope this explains what i was thinking. I thought i'd put it in feedback to get feedback, as there's bound to be things i haven't thought of.