Inventory OS

From Second Life Wiki
Jump to navigation Jump to search

An overview per Kelly Linden on sldev:

There are three systems involved here that are closely tied:
  • (DB) Resident Inventory lives in a database. We currently have lots of these 'inventory' or 'user' databases, each one hosting the entire inventory for a subset of our users. ex. UserA has all their inventory on db1, UserB has all their inventory on db6. The database entries are the shortcuts / links to actual assets.
  • (ASC) The actual assets live in the Asset Server Cluster. Any item in resident inventory or object inventory references an asset stored in the Asset Server Cluster.
  • (SIM) Items rezed and 'in world' do not have an asset that reflects their current state. They do have an 'original asset' reference, which points to the asset used to originally create the item when it was read but this won't reflect any changes made since rez. We don't save individual items that are currently in world to the asset server or any inventory database. We do save the entire state of a region every hour as a 'sim state' file - and this includes objects and their inventory items (as references to actual assets).

So, resident inventory lives in the (DB) and each item references one or more assets in (ASC). Object inventory lives in (SIM) and each item references one or more assets in (ASC). Items actually in world don't really reference any asset in (ASC) or anything in (DB). Keeping items inside the contents of objects in world and *not* in your inventory reduces the load of (DB) and may help keep your inventory loading faster, depending on how much you do it. It doesn't have any effect on (ASC) load though.

Attachments are the only case of an item in world that is also in your inventory, and the only case of an item in world that isn't in the sim state saves. That makes them doubly unique, and doubly fun. They also cross region boundaries far more than any other object, which has significant implications[1].

Feature Design Document

Documents needed:

  • Coalesed object returns.
  • Declined inventory offers should be routed to your Trash.

Functional Spec

Inventory Functional Spec

Test scripts

Inventory test

Exploit internal test

Container Permissions internal test

Preview Smoke internal test

Preview Smoke test

Inventory Multi Select test

Inventory Search Test

  • Coalesced object returns?

Discussion for future improvements

Inventory_UI_Design

Relationship to other features

List of features that need to be tested when this feature changes, and why.

Notecards Test - Notecards can hold inventory items(not calling cards) if their next owner permissions are fully permissive.

LLGiveInventory Test - Object Contents is inventory.

Group Permissions Test - Group Object Contents.

Inventory Permissions Test - Make sure the permissions are correct.

Item Permissions Test - Make sure the permissions are correct.

Next Owner Permissions Test - Make sure the permissions are correct.

Scripted Permissions Test - A different kind of permissions, but applies to attachments. (Scripted permissions really needs a name change to distinguish them from modify, copy, transfer permissions)

User Guides

Inventory on LSLwiki.net


Explanations

  1. ^ When an object moves from one region to another, the region must serialize the object and the contained scripts, including each script's state and event queues in addition to setting up the rerouting for Email, XML-RPC and HTTP.