Jump to content

Let's talk KVP store!


Troy Linden
 Share

You are about to reply to a thread that has been inactive for 3369 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

  • Lindens

Hi all. After reviewing the beta (thank you all for your participation!) we realized that the KVP storage is something that a lot of people are interested in. What I'd like to do is start a thread to learn more about your needs. Please reply with answers to:

1) Why you need it or what you would use it for.

2) How much storage would you need?

3) What are you doing now without the KVP? Explain your experience with external storage solutions.

4) Anything else you'd like to share about improving our KVP system?

Link to comment
Share on other sites

I've heard pricing has been finalized, but isn't ready to be published yet. I look foward to seeing it soon so I can see how feasible my ideas will be versus cost. In regards to the questions:

1) I have many applications that would use it. Some have yet to be created as they will require grid-wide keys and I don't want to give away too many ideas at this time as I'd like to be the first out the gate with those products when experiences are finally available to everyone.

2) Variable due to cost, application and/or popularity.

3) My primary application that doesn't use the KVP store is a region teleporter system.

4) What I hope comes into fruition later is a means of "partitioning" the KVP store under an experience. This may be possible with child experiences and allow quicker and easier KVP store maintenance with a particular application instead of having to check every single key of an overall potentially huge KVP store. It will also be a more attractive alternative to purchasing an additional entire experience as well.

 

Link to comment
Share on other sites

I dunno what KVP stands for, but if yur talking about the persistant storage in XPtools...

1. The sorts of things i can imagine persistant storage would help with, is more repliable and easier storring of scores, leveling up, posittions in an experience or story. Storing inventory collected through out an experience.

2. i have no idea about these things. But if limited to a certain amouth of memory then i would want easy ways to manage stored data.

3. Currently for a game where people clock into a factory every day im using an external MySQL database hosted on my web server. I created an inworld interface to manage scores and factory workers, and also created a web page to view the stored data. I found it very hard to channel data from SL out to an external Database, i still dunno how i did it!

4. I find it really hard to visualise the data thats being stored in the XP persistant Storage. With MYSqL you at least have an interface/dashboard to see what ever data, tables, etc is being stored on it. I've messed around with XPtools and storing data, i dunno whats stored in there now. Maybe i could call a "whats in there?" script command or sumfin.

Link to comment
Share on other sites


1) Why you need it or what you would use it for.

2) How much storage would you need?

3) What are you doing now without the KVP? Explain your experience with external storage solutions.

4) Anything else you'd like to share about improving our KVP system?

AFAIK, this forum is still limited to beta participants, and we're a sample selected for having at least once devised a story about a game-like Experience. The larger scripting community is apt to want to use KVP for much broader applications, as I hinted in a much earlier thread about using it to register ephemeral URLs of in-world http communications. This came to mind because all options for grid-wide inter-object communications have been so limited, always. (Specific to this http URL registry, using llEmail to exchange those URLs is vulnerable to some pesky intermittent bugs, and the other kludge of using external servers as a registry of internal URLs introduces an ugly network vulnerability.)

I've not yet tried this, but I've toyed with using KVP for the basic grid-wide communication itself, not just as the (much lower bandwidth) address registry mentioned above. In one of my applications, polling KVP for messages on a 1 Hz timer would be fine, with a circular buffer of, say, 100 message rows (perhaps a few thousand characters total) accessed by a handful of asynchronous writers and readers. Given these data volumes, this probably shouldn't overtax KVP, but at a larger scale this kind of comms might be a significant load on KVP resources.

Such communications-supporting uses of KVP don't rely on avatar permissions at all, so aren't really Experience-related.

I'm sure there are plenty of other, similarly non-Experience applications of KVP. For example, there used to be (maybe still is) an animator who kept an external database of... well, I'm not sure anymore, but something to feed their Animation Override products. One could imagine wanting something like that to "learn" by amassing data across many users, and be accessible to all those users while interacting with the scripts. As currently formulated, a grid-wide Experience key would be needed to access KVP on any parcel, but such an application doesn't actually need Experience-based avatar permissions.

Link to comment
Share on other sites

For breedables, it could store:

The state of a breedable:

  • age,
  • growth,
  • hunger,
  • thirst,
  • skins
  • etc

It could store a reference to all possible assets related to the breedable:

  • Skins
  • Sculptmaps
  • Animations
  • Sounds
  • etc

For the users, it could track the users of the breedable:

  • How many breedables
  • What level of breedables(average/highest)
  • deads

 

 

Link to comment
Share on other sites

Imagine I create 100 high quality prim houses. I store each prims complete parameters inside the KVP. Now I sell a subscription or just a lump sum to all my houses, and provide the seller with a box/hud from wich each house can be constructed prim by prim. 

This can be repeated with any prim based product range. A lot more convinient then with a external database.

You could use it for changing art work, that pulls the KVP for the chances. I could almost see a system that could make people see me life watch my work in progress by having a system that constantly sent my build updates to the KVP and objects around the grid that constantly update to my work.

 

Ofcourse prims is being supplanted by mesh, so the desirebilty of these kind of system might not be that great, but non the less, they would be more easiler made with the KVP. 

 

Link to comment
Share on other sites

  • 5 weeks later...

Right now the data I have sitting in Azure Tables for something I would like to have use KVP once gridwide keys become available is using about 840KB for ~1300 entries, I would assume once converted into JSON for each entity it would be roughly the same. 

 

The thing I would like to see the most is a way to visualize the KVP, that is really the only plus using outside storage has for me at the moment, as the KVP is far more convenient!

 

EDIT: Exporting my Table Entities to JSON resulted in smaller file size of 791KB

Link to comment
Share on other sites

  • 1 month later...

I haven't started using the experience stuff yet, but just looking at the docs for kvp I think it wouldn't be at all scalable (or anything I'd want to pay for) if I couldn't query whether a key exists other than to try to read it with a default value.

Also it makes sense to query for all the keys and get a paginated result in JSON, so you get back the first 100 or whatever, along with some range data. That way I can poke through it however I want to in one event loop, and you benefit from one query instead of 100. So my script would get data like this:

{"experience_key": "[exp key]", "range_start": 0, "range_end": 100, "keys": ["key", "key2", "etc"]}

It would be stale data as soon as you get it, because other scripts can kill keys, but it would be useful.

From there you could say llReadKeys(

  • , [default value]) which returns a strided list in one event cycle, also with a JSON counterpart which just adds JSON_INVALID for non-existent keys instead of a default.

I'm only endorsing JSON because LSL doesn't have structured data types. I'll be poking JSON into the KVP if i use it.

I'd really only want to scope this kind of stuff for an experience.

For grid-wide services I'd want data stores to be *way* more flexible, and I doubt LL wants to give me that. As long as llHTTPRequest() is free, I'm happy.

I already have a RESTful API I made for a kiosk system, which I was thinking might be something to try and convert to KVP under experience keys. But we shall see how much free time I have to devote to it.

 

Link to comment
Share on other sites

  • 4 months later...

I'm building an anime themed school that doubles up as a place to roleplay and learn together.

 

One of the more interesting ways I've thought about using KVP's, is to aid learning at the school through the use of KVP operated books.

 

Teachers would be able to 'write' to books by putting an image on each page and the book stores it's name, how many pages its got, and the uuid for the texture of each page in KVP's

 

These books could be distributed to students and would load their contents through KVP, enabling the editing of books by the author post-distribution (without having to send out new books) and also allow for collaboration if multiple authors want to edit the same book.

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3369 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...